Jump to content

Wikipedia:Village pump (proposals)/Archive 159

Add links
From Wikipedia, the free encyclopedia
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, 215

Establish a more firm policy about the notability of mass shootings and other events for WP:ITN Suggestion

I noticed that the shooting at Virginia Beach did not get its own blurb in WP:ITN, with the logic being that such an event is commonplace in the United States. True as that may be, further down the ITN there is a blurb about a boat collision which killed 6 less people.

So I think we should probably discuss what makes such a mass-casualty event notable. Should we have a blurb for every shooting that occurs which kills a certain number of people, regardless of location? What about other types of mass casualty events such as a fire or bomb? Should we consider the frequency that such events occur in different locations when determining whether or not we should have a blurb about it? I think having a firm policy in place will help prevent future accusations of bias. I welcome any discussions about this Rockstonetalk to me! 08:11, 3 June 2019 (UTC)

From what I see in the discussion, the reason why one went up on ITN and the other didn't wasn't a question of death toll (although the death toll of the boat accident might still increase), but a consequence of the fact that mass shootings are very common whereas (in the western world) such boat accidents aren't. Jo-Jo Eumerus (talk, contributions) 08:24, 3 June 2019 (UTC)
"I think we should probably discuss what makes such a mass-casualty event notable." That discussion occurs on a near-daily basis. At WP:ITN/C. In this case the view was, correctly, that the shoot-up did not warrant main-page coverage. You say that we should have a "firm" policy--is an ordinary policy not enough?--to prevent "future accusations of bias". There have been no accusations of bias in this matter let alone any rational accusations of that kind. So there is no need for a "firm" but equally macabre policy about minimum death tolls and the like. For what it's worth I wouldn't have posted the boat thing either but wikipedia editors seem obsessed with minor disasters and so be it. --Mkativerata (talk) 10:00, 3 June 2019 (UTC)
The current policy works well - we consider the quality of the article, the nature of the event, how frequently events of that nature happen in the same and similar locations, how the event compares to other similar events (including, but not limited to, death toll), what (if any) the long term significance of this looks likely to be, how wide the the coverage of the event is, and anything else that makes this event stand out as more or less significant than other events. The Stoneman Douglas High School shooting was posted because that mass shooting had several features that made it stand out from the crowd of similar events (mass shootings in the United States), principally the reactions to it from students and politicians and the impact on the gun control debate. The Virginia Beach shooting has had none of that. The Hungarian cruise ship sinking was an incident in a much smaller field (fatal sinkings of/collisions between passenger vessels on inland waterways in Europe and similar developed countries - browsing through the various lists of shipwrecks articles I can't find another similar incident that has happened worlwide in the last 5½ years; there were 43 mass shootings in the United States in May 2019 - the events are not comparable. The previous posted maritime incident of any I can recall was Sinking of MV Nyerere in September 2018 (overloaded passenger ferry sank in Lake Victoria killing 228). Thryduulf (talk) 13:32, 3 June 2019 (UTC)
  • If anyone wants a home for sorting policy, I welcome anyone to join Wikipedia:WikiProject Disaster management. To see an automatically updated list of all disasters in all languages, check out d:Wikidata:WikiProject Humanitarian Wikidata. @Rockstone35:, you asked what is common among fires, bombs, shootings, and boat accidents. These projects and other precedents group all such things together and imagine some common policy on them. Any comments or thoughts are helpful. Disasters will always happen, and articles on disasters are among Wikipedia's most popular, best covered, and most quickly produced articles. We have a strange social situation where people who develop disaster articles often only do one, rather than do them routinely, and perhaps for this reason Wikipedia has not established a stable community of people who routinely discuss disasters despite us having so much high quality content in this field. Blue Rasberry (talk) 13:58, 3 June 2019 (UTC)
  • See WP:CREEP for why some sort of "firm policy" is not a good idea.(this has been suggested and failed before.) Down the road we will have so many "firm policies" that this whole thing will be unworkable and not need participation from us; you can just program a bot to make ITN a news ticker in that case. Each event needs to be judged in context related to many factors as seen by readers/users. 331dot (talk) 14:09, 3 June 2019 (UTC)
  • I don't think any sort of firm policy in this area is necessary or desirable. Such cases should be decided individually by the good people at WP:ITN, and WP:CREEP plays a role. – John M Wolfson (talk • contribs) 22:36, 3 June 2019 (UTC)
  • We already have a policy, and it's ignored too often at WP:ITN/C. That policy is WP:No original research. In my view, at ITN/C, editors too often engage in original research to determine the importance of a topic.
    • You see it in the comments here, where a distinction is drawn between Stoneman Douglas High School shooting and Virginia Beach shooting because Stoneman "had several features that made it stand out from the crowd of similar events (mass shootings in the United States) principally the reactions to it from students and politicians and the impact on the gun control debate". The notion that Stoneman is special because of reactions and impact on the gun control debate is just one editor's opinion. I could easily point out that Sandy Hook shooting was exactly like Stoneman in the impact on the gun control debate, as was the Las Vegas shooting, which led to a near-nationwide ban of bump stocks. Similarly, I could say Stoneman is "special" because of the high number of casualties, in which case it would be in the same category as Virginia Beach shooting. Indeed, Thryduulf and I could go back and forth comparing and contrasting this shooting and that shooting, and it would all be impermissible WP:OR.
    • You also see it in the oft-repeated mantra that "mass shootings are common in the United States". That, by the way, is a bunch of WP:OR as well, and it's incorrect. The definition of "mass shooting" changes depending on who you ask. It might mean 3+ dead or 4+ dead. It might include the shooter in the casualty count, or it might not. Yes, if you look at 3+-dead-including-shooter shootings, there are a ton of them. But Virginia Beach shooting had 13 dead, and that happens less than once a year. Which brings us to the question of what does "often" mean. Because some editors felt that something that happens every year happens too often to be important enough to be put on the main page. By that logic, all mass-casualty events with 10+ dead, or 50+ dead, or even 100+ dead, would be excluded, because they happen too often. Using "often" as a dividing line to determine what gets on the main page and what doesn't is WP:OR. One editor can say once a year is often and another can say once a year is rare. Who decides? It should be the WP:RSes, not a majority !vote.
    • Meanwhile, sports championships, even those that happen annually, routinely get on the main page, if not as ITN/C then ITN/R. Editors deciding that a regularly-recurring sports championship gets on the main page because it's regularly-recurring, while a "mass shooting" (as editors define it) doesn't get on the main page because it's regularly-recurring... is, itself, total WP:OR. No reliable source "splits the baby" in this way–you won't find a newspaper that puts the snooker championship on page one for multiple days, while not at all listing a 13-casualty mass shooting. That is an "only on Wikipedia" thing... and probably some snooker magazines.
    • We may not need a "firm policy", but it might help to have a guideline for ITN/C that very closely follows our policies of WP:NOR and WP:V. We should, as in all things, follow the sources. If all of the international media are putting something on page one above the fold, it probably should be on our main page, too (subject to other considerations, like our article quality). If the media is ignoring something, it probably shouldn't be on our main page, either. I do see bias at ITN/C (and I don't participate there much because I don't want to fight with everyone constantly), and that bias is that editors use ITN/C as a way to right great wrongs by downplaying things they think the media over-covers and up-playing things they think are undercovered. WP:NOR is our policy that protects us from our own biases. – Levivich 18:56, 5 June 2019 (UTC)
      Some good points here, but it seems WP:NOR misapplied here to the area of doing research to determine notability and prominence. NOR is about "material—such as facts, allegations, and ideas—for which no reliable, published sources exist." It is not a prohibition on looking at sources to determine appropriateness for ITN. -- Fuzheado | Talk 16:42, 11 June 2019 (UTC)
  • Mass casualty events are routine occurrences in a world of 7+ billion people. It's depressing to see them on the front page continually. Some are obviously so notable as to be required, but it would good to see periods of rest from this type of article. -- — Preceding unsigned comment added by GreenC (talk • contribs) 19:26, 5 June 2019 (UTC)
  • The relevant policies are WP:N and WP:NOT. WP:ITN rests on these, and significance is determined by consensus, not a majority vote. Invoking WP:OR indicates that this policy is not understood; is permissible here, as it is in many areas of the project. WP:RS is not used, because what is important is not notability per se (all articles are supposed to be about notable subjects) but prominence. Caution should be taken when assessing news sources for prominence, because most major news outlets provide individualized experiences for each user, based on geography and browsing history. Just as we regard military and light air crashes as unexceptional (WP:AIRCRASH), so mass shootings in the US, which are routine, accepted and tolerated — 43 last month alone according to List of mass shootings in the United States in 2019 — are not regarded as newsworthy. (I like the bit about excluding gang-related killings.) Look at the sources in the list article. Most are local papers. As Thryduulf pointed out, ones with wider implications have a better chance of achieving prominence. Hawkeye7 (discuss) 20:01, 5 June 2019 (UTC)
    • Well of course I would not say that a random mass shooting which kills only a few people is prominent enough to be listed in WP:ITN, regardless of where it happened. Yes, 43 mass shootings occurred last month, but most did not kill anyone, and relying on the quantity of mass shootings in determining whether a particular mass shooting is notable is disingenuous. Mass shootings which kill many people remain very rare. The scale of the shooting (13 people killed) I think makes that particular shooting stand out. I would not agree that we should consider the location the event happened when determining prominence. If 15 people are stabbed to death in the UK, that should make it ITN, even though knife crime is common there. Rockstonetalk to me! 22:00, 5 June 2019 (UTC)
What if some "totally random" president "just loses it" and "fires" three formerly obscure staffers aboard his jetliner, completely arbitrarily? Of course we wouldn't disregard whether this "crime" happened in domestic airspace or foreign. Never make a firm rule you're not prepared to firmly defend, and don't think it could only happen to the guy we're probably all envisioning at the moment. Could even be a non-Canadian Prime Minister, best to stay flexible and ready for stories about anything (except sex), and I do mean anything. InedibleHulk (talk) 02:06, 24 June 2019 (UTC)
    • WP:N is not a policy. And Wikipedia is not a reliable source, so we shouldn't look at List of mass shootings in the United States in 2019, and based on that Wikipedia article, come to any conclusions about whether or not "mass shootings are common". That, to me, is what WP:NOR is exactly about. Don't draw any conclusions about mass shootings based on a list of mass shootings created by Wikipedia editors. If, for example, we want to base ITN decisions on the notion that "a 13-casualty shooting is commonplace", that should be based on the consensus of reliable sources, and not based on Wikipedia editors putting together a list and counting how many items are on that list. That's OR. It's also a pillar that "Editors' personal experiences, interpretations, or opinions do not belong", which is a principle that should apply to ITN decisions, i.e., don't base ITN decisions on editors' interpretations of statistics. – Levivich 21:57, 5 June 2019 (UTC) (ec)
      • ITN's own guidelines state "It is highly subjective whether an event is considered significant enough, and ultimately each event should be discussed on its own merits. The consensus among those discussing the event is all that is necessary to decide if an event is significant enough for posting.". By nature, the guidelines are subjective, which requires interpretation. If you want that changed, you may need to propose an RFC to do so.--WaltCip (talk) 15:47, 6 June 2019 (UTC)
        I'm not the right person to propose an RfC to change ITN guidelines, but I would support a change to specify that "significance" should be determined by WP:RSes and not by editors' WP:OR opinions. – Levivich 00:38, 9 June 2019 (UTC)
        I don't see how that's feasible. You're essentially asking someone to find a source that says "This boating accident is more important than the shooting earlier this week", which is obviously not going to happen. Matt Deres (talk) 19:57, 13 June 2019 (UTC)
I'll drink to that. Good point about the snooker mags, though, Levivich! In my opinion, anyway. InedibleHulk (talk) 02:15, 24 June 2019 (UTC)
    • At ITN we have a fake policy "WP:MINIMUMDEATHS" that we use to indicate that death count is not a sole deciding factor in whether we post news - it is all about context. If we has a confirmed terrorist attack in a location that never has been subject to one, which may have killed one or only none, but receives massive coverage, we may still post it. On the other side, we regularly do not post reports of hundreds killed in flooding in China and India regularly because these types of deaths are too frequent in those areas. And using event notability via WP:NEVENT is also bad because most notability can only be determined well after the event has happened after it fallen out of ITN. It is always going to be subjective at ITN and thus determined by consensus. --Masem (t) 15:59, 6 June 2019 (UTC)
  • ITN already has WP:ITN#Purpose which guides the selection of articles posted to the template. We could just jettison the whole "significance" criteria and use article quality as a gate, but I think some people like deciding what is "important enough" for the front page of Wikipedia. --LaserLegs (talk) 08:07, 8 June 2019 (UTC)
  • I think in the end, ITN/C is a reflection of pre-existing biases that exist among the editors, and it's always been like that. I disagree that there should be a given guideline to posting incidents, we have ITNR which fulfils the purpose it is supposed to but that is not something that can be applied here. To put it simply, I disagree with the premise that it was a fault in the first place that the Virginia beach shooting wasn't posted, or that the boat accident was. ITN/C is a way to garner consensus on the newsworthyness of news and whether it (and the article) is suitable for the main page and not anything else. Adding more bureaucracy to a non-existing problem is not the solution. --qedk (t 桜 c) 15:14, 9 June 2019 (UTC)

Create Wikipedia:Portals for Deletion or Wikipedia:Portals for Discussion

Miscellany for Deletion mostly consists of deletion discussions on portals. There are currently 35 portals nominated at MfD at the time of writing this. Compare that to Files for Discussion, which only has 14 discussions at the moment. Considering the fact that Wikipedia:Miscellany for deletion no portals exists, I'd think people would want this. InvalidOS (talk) 13:28, 12 June 2019 (UTC)

Seems like a solution in search of a problem - MfD seems to do reasonably well at the job. On a more cynical note, at the current rate we'd end up with an inactive XfD within a few more months Nosebagbear (talk) 15:00, 12 June 2019 (UTC)
I think that the current flood of portal-related deletion requests is ephemeral; there is a big clean-out of that namespace going and once it's done the number of portals in MFD should drop back to a manageable size. Jo-Jo Eumerus (talk, contributions) 19:21, 13 June 2019 (UTC)
No please, yes it is annoying at MfD right now, but I think these will be slowing back down. Over the long term, MfD is usually much more flooded with Draft:'s - and there hasn't been support to move those. — xaosflux Talk 19:56, 13 June 2019 (UTC)
Oppose. The current influx of portals should be a temporary issue. However the biggest problem is that the only people who would show up at Portal For Discussion are pro-portal crusaders against anti-portal-crusaders. That is a recipe for disaster. The entire topic would spin away from broader community consensus. While many editors would surely enjoy having the issue disappear from their view, that cluster will eventually orbit back to general community discussion in giant-drama form. In fact I wonder if the current separation of various XFD is really beneficial. Unifying them would result in a painfully long list (we might need to keep the list length manageable by running two 12-hour lists a day), but it would ensure more diverse participation in various kinds of XFDs. Alsee (talk) 07:45, 16 June 2019 (UTC)
Oppose per Alsee. The current tranche of MfDs are merely blip caused by an over-eager group of people trying to do bring Portals back to activity after a lot of criticism about them. That they went a little too far, too fast, but that is now being dealt with at MfD by the ant-Portal Brigade, and won't need a special place to deal with them in the future. Nick Moyes (talk) 16:00, 16 June 2019 (UTC)

Expanding InternetArchiveBot to handle book references

There is a clear consensus to implement the proposal.

Cunard (talk) 09:36, 14 July 2019 (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.

Since May 2015, User:InternetArchiveBot, aka IABot, has been continuously working to restore dead URLs by relinking them to archive snapshots. While IABot primarily links to Wayback Machine URLs, it’s able to handle over 20 different archive services. To date more than 10 million “broken” links have been repaired. This has helped a great deal to enforcing and maintaining WP:VERIFIABILITY.

Today, I am proposing a new feature of IABot to add links to referenced books from Archive.org. IABot will search for books referenced in enwiki articles and link to any it finds available at archive.org. Book references containing page numbers will link straight to those pages allowing editors and readers to more easily verify the contents of an article referencing the book. Here is an example of such an edit IABot would be making to an article.

An example of the benefit of this proposal can be seen on this article: Martin Luther King Jr. where pages from 54 referenced books are now just a click away from readers. For example Citation #1. As can be seen, any book reference with page numbers will make the title and the page numbers link straight to the desired page of the referenced book. References that have the title wiki-linked elsewhere will only have the page numbers linked.—CYBERPOWER (Chat) 17:45, 17 May 2019 (UTC)

Support

  • Support, provided that Archive.org's books are available everywhere. It'd be a more universal version of Google Books, although I wonder whether/how it would work for "short form" references. (e.g., given a book "Book" by John Doe, with an entry in a Bibliography but with inline citations of the form "Doe p. 54", would the bot work just on the Bibliography, on each short-form reference, or both/neither?) – John M Wolfson (talk • contribs) 18:06, 17 May 2019 (UTC)
    John M Wolfson, I just came upon a case with the shortened inline citations, and I don't see a reason why it needs to be supported. Reference 80 for example on https://wiki.riteme.site/wiki/Easter_Island#References reference "Diamond 2005, p. 109". When I hover over the author name, a tooltip pops up displaying the bibliography. I have both The Archive browser extension and The Archive wikipedia gadget installed, which were used to prototype this idea of referencing books with IA. Both of these tools are displaying links to the archive in the tooltip that popped up by hovering over "Diamond 2005". I am not sure if this will also work with IABot, but I think that it's likely considering it works already for 2 other tools that were used to prototype this feature of IABot. Reinischmax (talk) 19:59, 22 May 2019 (UTC)
    Reinischmax, that's probably because Template:Sfn is used in the refs, which is not always the case with shortened footnotes. I agree that Sfn should pre-empt any IABot activity with the shortened footnotes. – John M Wolfson (talk • contribs) 20:16, 22 May 2019 (UTC)
  • Support. Vulphere 10:07, 19 May 2019 (UTC)
  • Support. The Internet Archive is a top-notch, efficient, highly helpful, diligent nonprofit and this proposal would make our references more useful and open for our editors and readers, which is the same as what IABot and the Internet Archive have already been helping us do with web citations. In response to the oppose, IA books that are public domain are accessible for free without registration, and other books can be electronically "borrowed" free of charge (account registration is required in order to fulfill a legal requirement). No money ever changes hands, nor is there any advertising. We're being handed a wonderful service here, and I can't see any good reason not to take it. Making it easier to access references that are otherwise time-consuming and expensive to check will also improve the overall verifiability of our articles. Best, Kevin (aka L235 · t · c) 23:37, 19 May 2019 (UTC)
  • (Summoned by bot) Support Sounds like a good idea. SemiHypercube 12:24, 20 May 2019 (UTC)
  • Support. Always great to see non-profit projects working together for the benefit of the users of both and our shared vision of free access to knowledge. This is a no-brainer. Gamaliel (talk) 21:56, 21 May 2019 (UTC)
  • Support as long as it works in Europe with the copyright laws Atlantic306 (talk) 20:08, 22 May 2019 (UTC)
  • Support IAbot is great and this looks like an excellent idea. More like this please. – SJ + 15:25, 23 May 2019 (UTC)
  • Support Good idea. CoolSkittle (talk) 03:06, 24 May 2019 (UTC)
  • Support Good idea. Will be helpful to readers and will further the project. – Levivich 00:58, 1 June 2019 (UTC)
  • Support Fantastic idea! TheAwesomeHwyh (talk) 18:41, 2 June 2019 (UTC)
  • Support Making it easier for readers to view the original book is a great plan, and the implementation makes sense, especially given that IA and WP share a common goal of free and openly accessible knowledge. Siko (talk)
  • Support As per all the supports above, this makes great sense for readers and editors. (Disclosure: apart from being a Wikipedian/Wikimedian, I'm an IA advisor. And being both helps me see how the combination would help the common cause of free and accessible knowledge.) Anasuyas (talk) 20:10, 4 June 2019 (UTC)
  • Support.S Philbrick(Talk) 00:49, 9 June 2019 (UTC)
  • Support. SarahSV (talk) 01:28, 9 June 2019 (UTC)
  • Support Makes it easy for readers and in-line with the mission of Wikipedia.Vanischenu (talk) 02:44, 17 June 2019 (UTC)

Oppose

  • Neutral: My opposing opinion was based on misconceptions, so I'm withdrawing that. – Finnusertop (talk ⋅ contribs) 09:09, 24 May 2019 (UTC) Oppose This is part of a paid effort by Internet Archive (Cyberpower678 has declared) to advertise their new book loan service. There is nothing in it for us. The previews are by and large useless (they only display the covers, table of contents, and index), with the suspicious exception of books cited by the Martin Luther King Jr. article: I want to know if Internet Archive or the article has been modified specifically to feature pages that are "just a click away from readers", whereas this is overwhelmingly not the case with Internet Archive's preview with any other set of books. (see my comment below) – Finnusertop (talk ⋅ contribs) 16:58, 19 May 2019 (UTC)
    Finnusertop, See my response to your comment below. —CYBERPOWER (Chat) 17:11, 19 May 2019 (UTC)
    To be pedantic, the service isn't new; it's existed for at least a few years. The Open Library, which may or may not be the same service, has existed since 2006. Jc86035 (talk) 17:24, 19 May 2019 (UTC)
    I might also add that archive.org isn't advertising anything. User's are not required to loan out the book to see the referenced pages on the book. While the standard link only shows the covers of the book, IABot would insert a link going straight to the page of the book that is being used to reference material on an article. User's are however required to checkout the book, which is free, if they wish to access the complete copy, i.e. more than what is being referenced on the articles and the covers.—CYBERPOWER (Chat) 17:28, 19 May 2019 (UTC)

Discuss

Per my above support concerning various forms of inline citations, such as short-form citations common in FA's, parenthetical citations, and use of Template:Rp. I think the bot could and should work to link such citations as well. Here are some putative examples, using the Main Page as a dummy link:

  • Doe p. 54 -> Doe p. 54
  • (Doe p. 54) -> (Doe p. 54)
  • [1]: 54  -> [1]: 54 

References

  1. ^ a b Doe

I think the above assertion that we should apply the bot to such various cases if this proposal passes is fairly obvious. Less obvious is HOW the IABot would do so. I think it would have to see the text that's enclosed by <ref> tags (less such stuff as page numbers), and look through a section titled "Bibliography" or "Further Reading" to see if the matched text is present in a last name parameter of a template, and then scan the rest of the book data and make the requisite links. I'm not the most technically skilled and I don't mean to be an armchair coder, but just some food for thought. – John M Wolfson (talk • contribs) 18:23, 17 May 2019 (UTC)

Would there be a check on publication date / edition / isbn? Page numbers and textual contents can change between editions. If shortened footnote citations are used would it be best to leave these alone and only alter the "works cited" listings without the page number links? Thincat (talk) 19:36, 18 May 2019 (UTC)

Thincat, right now, the idea is to do ISBN matching, but our analysis of the ISBNs shows that this can be problematic sometimes. So we are working to expand beyond ISBN matching. Right now IABot’s dataset is very conservative to ensure more accurate results. —CYBERPOWER (Chat) 18:12, 19 May 2019 (UTC)

Internet Archive has two kinds of books: Public domain books are immediately accessible to anyone and useful to link to. But that is not what this proposal is primarily about. The rest of the books on Internet Archive only provide highly limited previews. In order to access these books, you need to register and loan the book. Usually, the preview is just the covers, table of contents and index (so parts of the book that are unlikely cited). Extremely suspiciously, the pages that Martin Luther King Jr cites are the only pages those books have on preview. Cyberpower678: have you asked Internet Archive to enable preview of certain pages that are cited at Martin Luther King Jr, or modified the article to cite pages that are offered on preview?

This is a service that the Internet Archive is desperate to advertise on Wikipedia. After their plans to have our citations say "Donate book to Archive.org" fell through, this is probably the next best thing for them – but not us. We would be introducing en masse "convenience links" that simply privilege one provider over countless of others that loan or sell books. For this very same reason, WP:NOTADVERTISING, we don't add "convenience links" to Amazon or any other subscription service en masse. We already have metadata and ISBN, and that's enough for anyone interested in the book to find it through their preferred method, which may or may not be Internet Archive's loan service. – Finnusertop (talk ⋅ contribs) 16:58, 19 May 2019 (UTC)

Finnusertop, any book being linked straight to a page number is immediately visible to the reader clicking it. Try it out for yourself by inserting a page number into the URL. I am being paid to implement the bot, but I am not being paid to promote archive.org. I'm a Wikipedian first here. Unlike what you claim, I propose to the community gadgets, or bots, that benefit the community. This is not an advertisement whatsoever, as archive.org is a non-profit organization. This is a coordinated effort between the WMF and archive.org to make sources more readily accessible to ANY reader. So your claims of me pushing this out as a last ditch effort is unfounded. It was already planned since before the gadget came out to have IABot blue link books. The gadget was just an intermediate step to make it more quickly accessible to users. Note that we didn't push this after it fell through. —CYBERPOWER (Chat) 17:09, 19 May 2019 (UTC)
@Cyberpower678: thanks for answering my question and explaining how the preview works with specific page numbers as well as the development process. I'll have to give some thought to this. – Finnusertop (talk ⋅ contribs) 17:28, 19 May 2019 (UTC)
Finnusertop, Sure. I will be happy to answer any questions for you. Just know, our goal is to serve Wikipedia and the community. Not to advertise on it. Our goal is to make references more readily accessible. FTR, the donate book link was just an experiment to help archive.org expand its free library and in turn provide readers with free access. It will not be a part of this bot task as the very notion of it was rejected in the previous RfC. —CYBERPOWER (Chat) 17:34, 19 May 2019 (UTC)
How legal is this service for copyrighted books? Wayback gets away with archiving webpages, as does google, and while Google offers some limited book previews, I'm not sure how archive.org's racks up. I know archive.org generally strives to be legal, so I'm not thinking they are purposing violating copyright, but... --Masem (t) 23:55, 19 May 2019 (UTC)
IANAL, but to my understanding, for non-PD books, the way that the Internet Archive grants access to full books is by asserting that it's a library and merely digitally loaning the book to visitors. (They actually keep all the physical books for this reason.) That's why you have to "borrow" and electronically "return" the book if it's not PD in order to view beyond a snippet preview. Best, Kevin (aka L235 · t · c) 00:51, 20 May 2019 (UTC)

I don't see anything wrong with this in principle, but I'm a bit worried that it will feed the attitude that seems to be pretty common here that only sources that are freely available on the Internet count towards verifiability or notability. Such an attitude just leads to Wikipedia becoming a mirror of your favourite search engine, rather than an encyclopedia. Phil Bridger (talk) 20:36, 22 May 2019 (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.

Adding "supressredirect" right to File mover

As a file mover, I find that I often have to request the deletion of redirects made by me moving a file from a meaningless file name to a proper one. It would really be a lot of help to have the ability suppress the creation of redirects when moving files. It wastes both my and the deleting admin's time doing this and I believe that those entrusted with this user right can be trusted not to abuse this power. Obviously, file movers would have to know that they shouldn't use it when moving non-files, but I don't think this will be much of a problem.--Breawycker (talk to me!) 00:07, 17 June 2019 (UTC)

Surely file redirects from meaningless names should not usually be deleted. See wp:FILEREDIRECT. Thincat (talk) 08:10, 17 June 2019 (UTC)
File redirects are generally kept for attribution reasons, especially if the files are likely to have been reused elsewhere. However, most of the files requiring renaming right now shadow Commons, and should be handled with the help of suppressredirect. I'll note that this has been proposed before (1 2 3), including at the time of the introduction of the right. --AntiCompositeNumber (talk) 10:50, 17 June 2019 (UTC)
If you have a sufficient tenure and are regularly running in to this, you can request pagemover access just for this use case, as it already includes that permission. (It is redirectsuppression criteria 5) — xaosflux Talk 12:01, 17 June 2019 (UTC)
Yeah, I just was going to say that - also, Breawycker, WP:G7 does not apply to redirects created by a move (unless you uploaded the file/created the page), so you shouldn't be tagging redirects left behind by a WP:FNC#2 for speedy deletion as WP:G7 (nor should admins be deleting it, but sigh..) Galobtter (pingó mió) 12:59, 17 June 2019 (UTC)
File mover is pretty useless honestly, may as well combine it into the page mover userright Satellizer el Bridget (Talk) 01:06, 19 June 2019 (UTC)

Infobox style

Is there a particular reason why various infoboxes use different words to portray when the thing in question was founded? For example, Infobox university uses "established", Infobox organization uses "formation" and Infobox company uses "founded". For consistency, wouldn't it be better to agree on a common term and use it across all infoboxes. Perhaps "founded"? Morris Schaffer (talk) 18:19, 19 June 2019 (UTC)

The terms aren't synonymous. To found is to originate, create, initiate (something which continues to exist thenceforward); to establish is To set up on a secure or permanent basis; to form is To give form or shape to (all three from OED). A university is intended to last forever; a company is intended to last until it goes bankrupt or is absorbed by another company; an organisation isn't necessarily intended to be permanent, as they often have a specific objective and are dissolved once that objective is met or becomes unattainable. ‑ Iridescent 20:02, 19 June 2019 (UTC)

running a bot to upload pdf versions of Wikipedia books to Wikipedia

Hi,

since there is currently now way to download PDF versions of books from the Book: namespace and there are currently no plans to implement such a feature I propose that I run a bot to create such PDF versions and upload them to Wikipedias File: namespace. This way users can directly downloaded them from the pages in the Book: namespace. I expect to update each of them once in 200 days.

The following examples show how PDFs will look like:

https://drive.google.com/drive/folders/17g5Ey6jauKd3CLMDNBOnV3RYKcJN0QZu?usp=sharing

This proposal was started in idea lab on 19 May 2019:

Wikipedia:Village_pump_(idea_lab)/Archive_29#Re-enabling_downloadability_of_Books_/_Collections

Dirk Hünniger (talk) 21:25, 19 June 2019 (UTC)

Category:Wikipedia books (community books) shows about 6,700 books is that how many would be added to File: space? -- GreenC 16:32, 20 June 2019 (UTC)
My goal is to add all of them. Still there might be some unforeseen effects. So I expect something like 90 % within the first two years to be quite realistic. I currently expect a disk usage of around 300 GBytes in total. Dirk Hünniger (talk) 16:47, 20 June 2019 (UTC)
Thanks. Seems like a reasonable idea. My only thought was Commons but since this is specific to Enwiki makes sense to organize files locally. -- GreenC 17:23, 20 June 2019 (UTC)
Question... I am unclear as to the purpose of the bot... How do you envision our editors using it in an article? Blueboar (talk) 17:15, 20 June 2019 (UTC)
It's not a user run bot. It creates PDF files of Wiki Books and uploads them to File: space. It's so end-users can access Wiki Books in PDF format. -- GreenC 17:23, 20 June 2019 (UTC)
Ok... but why do our editors need to access Wikibooks in PDF format? Do you see it helping with citations or something?
I get that you want to use Wikipedia as a host for these PDF files, but I’m not sure if that is our function. I don’t see how hosting these PDFs benefits Wikipedia and our function as an encyclopedia. Blueboar (talk) 17:35, 20 June 2019 (UTC)
FYI it's not my proposal ("you want to"). We already hosts these books in the Book: namespace. There is consensus for this content to be hosted on Wikipedia. I don't see a problem making it available in PDF format. -- GreenC 17:58, 20 June 2019 (UTC)
The value of these PDFs is that they reflect the current version of the articles. Having fixed PDFs would be rather pointless. Headbomb {t · c · p · b} 18:25, 20 June 2019 (UTC)
The PDF are going to be updated regularly. The update frequency is a question of computational resources, and thus money. The advantage is that the PDFs can be downloaded in seconds even for large books containing hundreds of articles, while the PDF generation might take hours in such cases. I am planning to add a link to the PDF file of each book on the page of the book in the booknamespace. So there is nothing changed in the experience of our editors. Its just going to change the experience of end users who are in need of getting a full copy of book in the book namespace. The on demand rendering is already available here: http://mediawiki2latex.wmflabs.org/ http://mediawiki2latex-large.wmflabs.org/ Dirk Hünniger (talk) 18:49, 20 June 2019 (UTC)
How do you plan to license these? Specifically, are you going to include all authors in the book? Are you going to exclude fair-use images? — xaosflux Talk 17:41, 20 June 2019 (UTC)
Yes as you seen the PDF I provided as examples above there is a list of figures and a list of contributors at the end of each PDF file. The files will be licensed under the same license as Wikipedia itself. Currently fair use images are included, but it is easy to exclude them in case there a consensus decision to do so.Dirk Hünniger (talk) 18:49, 20 June 2019 (UTC)
@Dirk Hünniger: I don't normally follow third party file hosting links, you could put your example here for better accessibility. — xaosflux Talk 18:51, 20 June 2019 (UTC)
Hi, its a bit of funny since I think I am not supposed to upload such a file to Wikipedia and I am just requesting to upload such a file in this very discussion. So a very nice case of recursion. But fortunately someone else has already done so, although its just a single article: File:Ion Keith-Falconer from German Wikipedia converted with MediaWiki2LaTeX.pdf
Thanks, so assuming these are not going to try to include fair-use images - wouldn't you just put these on commons? — xaosflux Talk 19:06, 20 June 2019 (UTC)
Well for now, I include fair use images. And as long as there is no consensus decision to exclude them I am going to keep the included. And this why I am currently proposing to upload on the English Wikipeda.Dirk Hünniger (talk) 19:10, 20 June 2019 (UTC)

Share your Input on Convergent Community Values about Algorithms on Wikipedia

We are a group of researchers at the University of Minnesota collaborating with the Wikimedia Foundation to improve ORES, a machine learning-based algorithmic service designed to automate critical wiki-work (e.g. vandalism detection and new page patrolling). Our research team is carrying out a Value-Sensitive Algorithm Design (VSAD) process in order to engage Wikipedia community members and incorporate their tacit values, knowledge, and insights into how ORES should work in the future. You can find the full study description here.

Our team has completed interviews with 16 stakeholders, including five (5) Wikimedia Foundation employees, two (2) external researchers who use ORES in their work on Wikipedia, two (2) volunteer developers who have built ORES-dependent applications, and seven (7) editors with varying degrees of experience on Wikipedia.

Our interview data indicate that there is broad agreement across stakeholder groups about what is most important when it comes to designing machine learning algorithms, and applications that depend on those algorithms. We have derived five major values that should guide future development efforts related to how algorithms ought to operate on Wikipedia. The purpose of this post is to give the broader Wikipedia community a chance to weigh in on our interpretation of the data.

If you are interested in viewing our derivation of these values from our interview data, please view and comment on the current draft of our results here. (We will eventually publish these results in an academic, peer-reviewed venue.) The five “convergent community values” are as follows:

  1. Algorithmic systems should reduce the effort of community maintenance work.
  2. Algorithmic systems should maintain human judgement as the final authority.
  3. Algorithmic systems should support the workflows of individual people with different priorities at different times.
  4. Algorithmic systems should encourage positive engagement with diverse editor groups, such as newcomers, females, and minorities.
  5. Algorithmic systems should establish the trustworthiness of both people and algorithms within the community.

Feel free to share your thoughts here, or leave comments on the google doc draft, or talk us at my or Estelle's talk pages. Thank you for your time and thoughtful consideration!

Bobo.03 (talk) 20:44, 14 June 2019 (UTC)

  • I particularly like your CCVs. I also like the demonstration of what happens when individuals with different views talk to each other. Nosebagbear (talk) 19:50, 15 June 2019 (UTC)
  • I am extremely wary of the use of algorithmic systems in Wikipedia (I have seen too many cases where relying on algorithms resulted in unintended consequences)... so I am very pleased to see the second value listed above. Indeed, I am not sure it goes far enough. Humans can certainly use algorithmic AI as a tool, but we need to keep human judgement in the forefront. Blueboar (talk) 22:31, 15 June 2019 (UTC)
    • Thank you for expressing your wariness Blueboar. Yes, the second value emerged very clearly and repeatedly in our data. When you say it does not "go far enough," I wonder how the expression could "go further" to really capture the essence of what you're getting at? Our WMF employee participants were especially wary of unintended consequences, as you mention. Perhaps we need to highlight that more... FauxNeme (talk) 14:21, 16 June 2019 (UTC)
    • @Nosebagbear: @Blueboar: Yes, we do value having humans especially with different views in the process a lot. One of our current projects is working to develop an interface tool that can visualize algorithm/model tuning for different value trade-offs, e.g., error v.s. fairness, thus individuals with different views (or different stakeholders) can select a model that can address their primary concerns and discuss to make a collective decision about the model to be deployed in the community. Bobo.03 (talk) 14:28, 16 June 2019 (UTC)
  • The document appears to show an impressively high understanding of, and respect for, the needs and values of the community. In particular I believe editors will particularly appreciate the comments of P1 (a staff member), about keeping the balance of power in the hands of the editors using the systems.
    I'd like to note that any efforts at "establishing the trustworthiness of people" is a particularly sensitive area, and any ideas in that area would most particularly require careful consideration by the community. Regarding "diverse editor groups, such as newcomers, females, and minorities": I definitely support the goal itself, however aspiration for that goal often needs to be counterbalanced by critical consideration of proposed means for pursuing that goal. It is an area where I've seen too few positive results and a few too many metaphorical roads to hell paved with good intentions. It can lead to conflict when people let that ideal come into conflict with the ideals of Wikipedia policy. To cite an existing area of tension: Most editors welcome more articles on women and minorities, but most editors also oppose giving such articles a privileged pass in deletion-discussions. Favoring inclusion of obscure (non-notable) biographies is generally not considered an acceptable means of pursuing the goal. Alsee (talk) 11:13, 16 June 2019 (UTC)
    • Hi Alsee, you raise an excellent point. When I make an editing pass on the document after this discussion is over, I will do my best to incorporate your feedback and note the tensions you have pointed out. FauxNeme (talk) 14:21, 16 June 2019 (UTC)
    • @Alsee: Thanks for sharing your thoughts. Would you like to provide more insights about the conflicts of creating more articles on women and minorities. The goal of one of our ongoing projects is to promote gender diversity in Wikipedia contents, by creating a tool to help editors identify articles that are for instance more female related but may be underdeveloped. Does the idea sound appealing to you? Bobo.03 (talk) 14:37, 16 June 2019 (UTC)
      • Bobo.03: Helping editors identify articles of interest to work on shouldn't raise any issues, other than the routine stuff that arises when editing anything.
        Regarding new articles, I don't want to overstate the issue but I have seen some ugly messes crop up. (Ugly cases draw mountains of attention.) I have to cover a few points first, to explain what can go wrong. One of the things that allows us to function in a world filled with controversy is that we have policies and practices that isolate Wikipedia as a neutral non-participant in those issues. Some people think one political party is a noble cause, other people think the opposite political party is a noble cause. There is little tolerance for putting any cause ahead of Wikipedia policies. Wikipedia's job is create an accurate summary of all subjects (and all sides of controversies) that are published out in the world. Wikipedia is not a place to fight those battles. Wikipedia is not a place to try to fix the world's problems. Wikipedia isn't to be used to serve anyone's pet causes. If someone has a cause, our answer is for them to go fix it out in the world and afterwards we will update the encyclopedia to reflect that success. That unyielding approach means Wikipedia is almost equally intolerant of noble-cause crusades and bad-cause crusades. One of Wikipedia's rules is Notability - a topic (or a biography) is only allowed to have a Wikipedia article if there are sufficient sources of an acceptable quality. If someone is on a noble-cause to create lots of women biographies, they're not here motivated to write about a specific famous woman, they're here to dig up a bunch of random women to write about. Notice that the priority there is backwards, the femaleness of the article-subject precedes and takes precedence over how famous or Notable the person is. As long as all the new biographies are clearly notable, there's no issue. When the notability of one of those articles is questioned and a discussion is opened to consider possible deletion, there have been cases where the article-author interpreted that as an attack against the Noble Cause. Anyone seen as attacking the noble cause is, almost by definition, evil. Then there's a risk that someone, usually the article-author, calls in allies for the noble-cause. At this point normal debate about the sourcing and acceptability of the article goes out the window. It can turn into a warzone for the noble cause. People may show up to vote keep just because it's a female biography, disregarding Wikipedia article standards. People who argue the article fails our policy-standards may be accused of sexism (for opposing the noble cause). Good people end up battling against good people. Big ugly drama ensues.
        Back to the main topic, "positive engagement with diverse editor groups, such as newcomers, females, and minorities" is a good goal, but how do you accomplish that? The first obstacle is that On the Internet, nobody knows you're a dog. And beyond that, we haven't had much luck finding simple or easy solutions. We could give biographies on women/minorities privileged immunity to deletion-discussion, but I'm pretty sure most editors are opposed to padding Wikipedia with "junk biographies" to (poorly) serve a cause, no matter how appealing that cause is. Ideas for pursuing this goal likely need some level of community review. There may be policies or ideals that raise non-obvious concerns. Alsee (talk) 21:00, 20 June 2019 (UTC)

Rollback

I propose making rollback available on mobile devices (cell phone, iPad, etc...). I originally applied for rollback thinking that it would appear on a mobile device diff the same way it does on a computer. However, at this time, rollback is only on computers. I think it would be better to make rollback available on mobile devices is for convenience. LPS and MLP Fan (LittlestPetShop) (MyLittlePony) 14:45, 9 June 2019 (UTC)

This will be available as part of feature-rich mobile history page being developed as part of mw:Advanced mobile contributions project. A beta version has already been deployed on some wikis; see prototypes in this task. – Ammarpad (talk) 09:34, 11 June 2019 (UTC)
On mobile you can switch to the desktop interface. The writing is tiny, and you may have to zoom in to be able to touch the right link, but it can work. Graeme Bartlett (talk) 08:22, 14 June 2019 (UTC)
Plus it confirms that you meant to click on the rollback link to avoid accidental rollbacks.--Breawycker (talk to me!) 00:09, 17 June 2019 (UTC)
@Graeme Bartlett: you said that I can switch to Desktop Interface on mobile devices. How do I do that? LPS and MLP Fan (LittlestPetShop) (MyLittlePony) 05:41, 21 June 2019 (UTC)
Scroll to the bottom of any page in the mobile view and you can click on the link that says, "Desktop". Killiondude (talk) 05:43, 21 June 2019 (UTC)

Solomon's

Why is there no article yet on Solomon's harem? Reportedly it was a populous place. -ApexUnderground (talk) 01:47, 16 June 2019 (UTC)

See the section entitled “wives and concubines” in the Solomon article. It may be that there are not enough scholarly works written about it to support a full article. Blueboar (talk) 01:56, 16 June 2019 (UTC)
I'd like to see one on Solomon's mines, but I think there's a lack of sources there too, Solomon doesn't mention anything outside pop-cult. Gråbergs Gråa Sång (talk) 22:56, 16 June 2019 (UTC)
see King Solomon's Mines, and In Search of King Solomon's Mines and there are also several articles about the films. eg The Search for King Solomon's Mines. Graeme Bartlett (talk) 11:46, 21 June 2019 (UTC)

FPC needing feedback

Hi all! I proposed an image on WP:FPC and it didn't reach the quorum for one vote. For days it was on "FPC needing feedback" yet it didn't work. Any idea?, shouldn't FPC needing feedback receive a further time to reach consensus? Thanks! --LLcentury (talk) 15:08, 23 June 2019 (UTC)

@LLcentury: You seem to have nominated a number of images at WP:FPC. Which one are we talking about? --Redrose64 🌹 (talk) 15:31, 23 June 2019 (UTC)
@Redrose64:, sorry for not being clear Wikipedia:Featured_picture_candidates/Byun_Yo-han. --LLcentury (talk) 15:33, 23 June 2019 (UTC)
This was closed by Armbrust (talk · contribs). Have you asked them why they reached that decision? In any case, I don't see why this is a WP:VPR matter: are you proposing a new process that would be different from the processes that already exist? --Redrose64 🌹 (talk) 15:59, 23 June 2019 (UTC)
The nomination failed because it didn't reach the necessary quorum (5 supports) during the voting period (10 days). As an image can be renominated at any time, I don't think expanding the voting period is needed. Armbrust The Homunculus

No no just a proposal to expand the time of those pictures needing feedback. Sorry my English is not expansive. --LLcentury (talk) 16:00, 23 June 2019 (UTC)

“Thank” button in signature.

I suggest adding a “thank” button in the Wikipedia signature to be able to thank faster without searching the revision history. Example: –Chanc20190325 (talk • thank) 13:55, 2 June 2019 (UTC)

  • Oppose. Benefit: Saving of perhaps 20–30 seconds for most thanks, for the small fraction of comments that receive thanks. Cost: About 35 characters of additional markup in the wiki editor window, for every comment posted by a registered editor using the default signature. Cost exceeds benefit. AFAIK there is nothing currently in signature policy to preclude this in a customized signature. ―Mandruss ☎ 14:34, 2 June 2019 (UTC)
    @Mandruss: Except from a technical standpoint, thanks depends on REVISIONID data, which can not be substituted. So while you could link a link to thank me for something static I did in the past (e.g. (CLICK HERE TO THANK ME FOR BEING THE BESTEST) you wouldn't be able to thank me for the edit related to that instance of the signature. — xaosflux Talk 16:07, 2 June 2019 (UTC)
    I think you're saying that this would be impossible in a customized signature. I can live with that. ―Mandruss ☎ 16:40, 2 June 2019 (UTC)
  • Oppose. I really do not think it's necessary, maybe it will save you a few seconds, but I think the editors are here to improve Wikipedia and not for recognition.--AnbyG (talk) 08:41, 3 June 2019 (UTC)
  • Comment - I like the idea, but also get that adding additional markup/text in each instance of a signed comment could add up to a lot. I wonder if there's a way to handle this with a script for those who want it? Perhaps pulling a diff based on the timestamp/name? — Rhododendrites talk \\ 20:18, 4 June 2019 (UTC)
  • Oppose per others. Millbug talk 03:27, 7 June 2019 (UTC)
  • Oppose per others.--Vulphere 17:26, 12 June 2019 (UTC)
  • @Enterprisey: Did you have some gadget which provided this functionality? I thought that you did. Blue Rasberry (talk) 19:35, 12 June 2019 (UTC)
  • Leaning oppose. The vast majority of times that I thank someone, it is because I am already looking at the specific diff to see what they've added. I don't know if this is the common experience, but surely I can't be the only one doing that. bd2412 T 02:10, 17 June 2019 (UTC)
    I'm the other one, you're not crazy. InedibleHulk (talk) 02:40, 24 June 2019 (UTC)
  • Oppose, but might be a good idea for a user script. Anne drew 14:02, 19 June 2019 (UTC)
  • Oppose The easier it gets to thank people, the less genuinely thankful other people need to be to instaclick a button, and the more our notification feed is oversaturated with platitudes from merely suggestible folk. You think Kanye West feels any sort of joy when he gets a like, thumbs up or booty call anymore? It could happen to any of us in the public eye, best to set a simple impulse barrier, like we have. InedibleHulk (talk) 02:35, 24 June 2019 (UTC)
  • This could definitely be written, but the script would have to dig through the page history to figure out when a particular comment was added. If there's enough demand, let me know. Enterprisey (talk!) 05:14, 24 June 2019 (UTC)

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

In the previous RfC there was a rough consensus to develop the functionality presented here, but there was no consensus to implement the changes. This RfC asked whether there is now consensus to implement these changes. There is still no consensus to implement these changes. For context, the previous proposal was supported by a roughly 2 to 1 margin (about 15 to 8), this proposal was supported by a roughly 1 to 1 margin (about 15 to 14).

The supporters point out that the proposal would save a good deal of editor effort. When a page on commons is moved the hardcoded links break, but Wikidata is automatically updated. With this proposal, links would no longer break due to page moves. Some point to other benefits such as simplified wikicode and ease of use for newcomers. They contest the opposition argument regarding vandalism, saying that the risk is minimal and the benefits outweigh any such risk.

The general opposition is to the removal of locally defined data. The commons page to which an article links is currently subject to local consensus, and implementing this proposal would result in some pages having content which is not subject to local consensus. Additionally it would make it hard for readers and new users to fix errors because a template with no parameters does not make it clear where the data is coming from. They also disagree that the benefits outwiegh the risks of vandalism, pointing to the consensus against using WikiData for short descriptions and arguing that the benefit of using Wikidata for short descriptions did not outweigh the risk of vandalism.

Given the strong arguments on both sides, and the significant level of opposition in this proposal (especially in relation to the previous proposal) there does not appear to be consensus to implement this proposal at this time. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 08:43, 25 June 2019 (UTC)

Should we remove locally-defined links to Commons categories where they can be provided through the Commons category sitelinks on Wikidata instead? Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)

Proposal (Commons category links)

While we have been using interwiki links from Wikidata to provide the sidebar links to other language Wikipedias for the last few years, we are still mostly using locally defined links in sister project templates. In an RfC in August 2018, starting to use Wikidata to provide these links in the case of Commons categories was conditionally allowed, with the requirement to return to the community after further testing, which leads to this follow-up proposal.

Since the previous proposal, the following things have changed:

As the next step, I propose to bot-remove the locally-defined Commons category names from the categories and pages in Category:Commons category link is on Wikidata, where they match the Commons sitelinks from Wikidata. If this proposal is accepted, then I will submit a bot request for approval to do this using Pi bot. This change should have no immediately visible effect, but any future changes to the category names on Commons would automatically be updated here. This would not affect any locally-defined Commons category links that are not on Wikidata.

Pinging those that !voted in the last proposal: @Robby, Rhododendrites, Alpha3031, AfroThundr3007730, Johnbod, Jo-Jo Eumerus, Fram, Izno, GermanJoe, Compassionate727, Keith D, Peter coxhead, Ammarpad, Killiondude, Rschen7754, Nihlus, Finnusertop, ARR8, Gamaliel, Bidgee, Bluerasberry, GreenMeansGo, PBS, Wikisaurus, and Nemo bis:

Pinging as well those that modified template Commons category since 2015 and thos e who discussed the same category on it's discussion page: @Ahecht, Redrose64, Fayenatic london, Rich Farmbrough, Pigsonthewing, IJBall, Magnolia677, Andy Dingley, JJMC89, Zhanlang1975, Michael Bednarek, Krinkle, and FunkMonk:

Survey (Commons category links)

  • Support as proposer. Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)
  • Oppose now – see below. Cluttering articles with links to Commons when these are in the sidebar isn't desirable. However, my support is conditional on the point noted below, that only the Commons category link that matches the Wikidata link is removed. (As has been discussed, here and at Wikidata, many times now, there are problems caused by Wikidata insisting on 1:1 inter-wiki relationships, when for various reasons different wikis, including Commons, don't have 1:1 links – e.g. for monotypic taxa, enwiki has one article, whereas Commons usually has a category for each rank.) Peter coxhead (talk) 09:51, 6 May 2019 (UTC)
    @Peter coxhead: Just to be clear, the proposal is to go from e.g., {{Commonscat|Example}} to {{Commonscat}} where the Commons sitelink on Wikidata is "Category:Example". The template itself would not be removed. Thanks. Mike Peel (talk) 10:32, 6 May 2019 (UTC)
    @Mike Peel: ah, my mistake. Then I now Oppose the proposal. So long as the template is present, then as with {{Taxonbar}}, I think it's better to explicitly document the connection. A tracking category is enough to flag up cases where none of the stated commons cat links matches Wikidata, as happens for {{Taxonbar}}. What I favour is removing the template altogether when the link will be in the sidebar. Peter coxhead (talk) 11:12, 6 May 2019 (UTC)
  • Support - as long as the Commonscat template is kept available for non-standard situations, this should be an unproblematic and reasonable change. GermanJoe (talk) 11:08, 6 May 2019 (UTC)
  • Support with the general expectation that only the matching values are removed. --Izno (talk) 11:38, 6 May 2019 (UTC)
  • Support Pages that link to more than one cat or have special need to keep the local link should be exempted, otherwise this is good. – Ammarpad (talk) 14:28, 6 May 2019 (UTC)
  • Fine by me. I can't comment on the technical details as they're beyond me (as usual). But in principle I don't see any issues. GMGtalk 20:58, 6 May 2019 (UTC)
  • Support - the Commonscat template should be kept available for non-standard situations. --Robby (talk) 21:22, 6 May 2019 (UTC)
  • Support this as a sensible next step — Martin (MSGJ · talk) 21:46, 6 May 2019 (UTC)
  • Oppose: The commons category listed in the Wikipedia article is the "ground truth", that is, users who actively contribute/watch to that article are presumably in consensus that this (or these, where there are multiple commons categories) is the most appropriate Commons category for this article. The information on Wikidata is merely a copy. Users who contribute to articles care about keeping them correct and safe from vandalism and often have real world topic knowledge, users who contribute to the Wikidata Qnumber are acting more in the role of a database administrator and are generally not familiar with the topic. By all means, take a copy of this into Wikidata but do not destroy the original information on Wikipedia. Firstly because that is a generally poor practice to remove authority over information from subject matter experts to database administrators, but more specifically because if someone vandalises the information on Wikidata, it will not show up on the watchlists of those who watch the Wikipedia article and damage will go undetected. It is one thing to exploit Wikidata information where the information starts its life on Wikidata (e.g. as an uploaded data set from some authoritative source). Rather than remove the information from Wikipedia, it would be better to add a template to flag on both Wikipedia and Wikidata where there is an inconsistency between Wikipedia and Wikidata, as I have seen done with coordinates, which is an invitation to investigate the matter and not impose the presumption that what is on Wikidata is always the "truth". We already have the ability for a commons category template on Wikipedia to default to the article title, and I never use that feature as I have seen too many times when the articles is renamed and nobody thinks about the implication of that move on the commons category (which has normally not been renamed). Kerry (talk) 23:50, 6 May 2019 (UTC)
  • Support I don't see any issues. Go on. Sincerely, Masum Reza☎ 04:40, 7 May 2019 (UTC)
  • Support seems like a smart move -- reduces clutter in the markup, Sadads (talk) 18:13, 7 May 2019 (UTC)
  • Oppose Per Kerry's extremely well written and reasoned comments above. Beeblebrox (talk) 20:23, 7 May 2019 (UTC)
  • Oppose - If Wikidata isn't stable & nuanced enough for short descriptions, then I don't think it is for this either. I think it would be better to keep the info locally and have a bot set up a list or drop a notice on the talk pages of articles with differing cats or where only Wikidata has a cat. Daß Wölf 22:17, 7 May 2019 (UTC)
Wikimedia Commons has media related to Something.
  • Oppose. Compare the Commonscat box at right with the Wikidata link in the toolbar, and imagine a Commons link, or any other inter-project link, in the toolbox at left. Which one's more visible? As a longtime admin on both sites, I'm quite familiar with our layout, but I virtually never think of inter-project links appearing on the left, aside from other languages' Wikipedia articles. What about the newbies or those who never edit: do we expect them to find Commons links amid all the other stuff? It's much more reader-friendly to have a sizeable right-side box or an entry in the external links than to bury a link on the left side with lots of other things that are mostly irrelevant to someone who's not editing. Nyttend (talk) 22:44, 7 May 2019 (UTC)
    @Nyttend: You may want to reread the proposal. The box would stay in either case. ARR8 (talk) 00:28, 8 May 2019 (UTC)
  • Support per nomination. ARR8 (talk) 00:28, 8 May 2019 (UTC)
  • Oppose An edit that does nothing but remove local information that is already on Wikidata is functionally cosmetic. Bots performing cosmetic edits are not allowed per policy. * Pppery * survives 00:42, 8 May 2019 (UTC)
    You seem to have mischaracterized Wikipedia:Bot policy#Cosmetic changes. A bot implementing community consensus is specifically allowed regardless of whether the edit is cosmetic or not. Anomie⚔ 11:19, 8 May 2019 (UTC)
    @Pppery: As well as Anomie's point, I think it falls under "administration of the encyclopedia" - it's preventative maintenance. Thanks. Mike Peel (talk) 19:04, 8 May 2019 (UTC)
  • Oppose I agree with what Kery has said, to me the bigger issue is creating a process with excemptions as we know from practice that exemptions are rarely accepted once a policy is written, as groups of editors haunting the discussion boards see it as means to enforce uniformity and standidise everything to their preferred format. What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link Gnangarra 05:56, 8 May 2019 (UTC)
  • Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Wikipedia, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee (talk) 16:26, 8 May 2019 (UTC)
  • Support This is safe, raises quality, saves humans from tedious labor, stages content from English Wikipedia to migrate into other languages of Wikipedias, and this small project is a model for greatly scaling up integration of English Wikipedia with automated tools. I am keen on eventually using more automation in English Wikipedia for quality control and monitoring. We do not have the technology to apply automation generally everywhere, but for mundane things like limited category maintenance, automation and integration with Wikidata is a good fit for being unlikely to cause problems and likely to prevent problems. I recognize that people here fear wiki editors developing annoying edit bots, but personally I fear and am seeing bad actors with malicious bots attacking Wikipedia. We are entering an arms race and I want us to develop our technology and also advance conversations about how humans and bots will collaborate to sustain Wikipedia. The bad actors do not follow rules, and I want us to start the slow conversations with good actors and safe cases as we see here. I do not see this primarily as a technical experiment, because this proposal is so small in scope and so safe. Instead I see this as a social experiment for how we negotiate the introduction of quality control bots into English Wikipedia and across Wikimedia projects. I interpret the opposition here as resistance to Wikidata, slippery slope that this change pre-approves future risky changes, and resistance to bots consuming human attention on English Wikipedia. I definitely agree that bots cause stress to humans, but I see the solution to that as research, discussion, planning, and experiments, and not in an ongoing prohibition of this necessary and inevitable change. Relatively low-impact proposals like this are good experiments to get information about how bot-Wikidata-Wikipedia interactions play out. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)
  • Support As reduces issues when categories are renamed. -- WOSlinker (talk) 07:50, 9 May 2019 (UTC)
  • Oppose this scope creep of the obscure, poorly monitored Wikidata needs to stop. Plus, Kerry says it well, especially in the discussion below, eg: And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. . - Sitush (talk) 07:58, 9 May 2019 (UTC)
  • Strong support (and actually, for most sister links). The links do often not lead to significant / more information - what is the use of looking on commons if I see exactly the same image or see 11 images on commons while 10 of them are already used in our article. And if there are images there that are of real significance, then they should be used (e.g. in a gallery). Commons categories often contain mostly the images already used in the article (and a promise that the commons category will/can grow is WP:CRYSTAL). I can see that there is sometimes a reason to include sisterlinks, but that should absolutely not be a standard, it should be a well considered and one should be allowed to challenge existing links based on content, not being countered with the argument 'it is standard' or 'we do that always'. --Dirk Beetstra T C 08:23, 9 May 2019 (UTC) I read this wrong, Oppose, this is not removing the sisterlinks from the bottom of the article, this wants all to be done through WikiData. WikiData is poorly monitored, local content should always have preference. --Dirk Beetstra T C 08:26, 9 May 2019 (UTC)
  • Support. Vulphere 12:26, 11 May 2019 (UTC)
  • Oppose per Kerry, and because of problems of consistency when more than one commons link is desirable in a Wikipedia article, which I think would be confusing after this suggested change. I think that Gnan's suggestion "What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link", could be worth pursuing as a compromise. -- PBS (talk) 17:01, 11 May 2019 (UTC)
  • Oppose per Kerry. I'm all for flagging pages where the template and wikidata don't match by putting them in a category for manual review, but vandal-fighting over at Wikidata isn't robust enough for us to be trusting it as an authoritative source. --Ahecht (TALK
    PAGE    ) 21:57, 15 May 2019 (UTC)
  • Support This is a change that will allow us to better serve readers and editors alike by automatically updating data for the 99% of cases where Commons/Wikidata was updated correctly – Instead of preventing 1% of potential incorrectness at the cost of being outdated and likely wrong by default for 100% of cases, with no notification to editors that watch articles to know whether something might need fixing, until someone manually realise it (which is what we do today). There is currently no technology in place to notify us about a Commons category rename. What we do have is Wikidata. Commons users update this for us already (or even automatically, in case of simple page rename on Commons). This data can in turn be queried from articles. In addition, Wikidata has the ability to notify us (as Wikipedia editors) directly on our watchlists whenever such manual or automated change from Commons/Wikidata affects an article we watch. As such, we would still have the ability to review and fix these as-needed. I believe this fits in with a wider theme of giving ourselves more time to focus on the things that matter (e.g. reviewing meaningful changes to articles on our watchlist, improving the quality and breadth of our content), and demand less wasted effort on people manually fixing things that we could have prevented from breaking in the first place using a bit of automation. --Krinkle (talk) 22:35, 15 May 2019 (UTC)
    For those that oppose, I wonder what their opinion would be on a proposal for a bot that updates these templates automatically as an edit whenever the previous value on Wikidata matches the current value on Wikipedia (effectively the same proposal with similar Watchlist events, but more wasteful toward the limited time and resources that volunteer bot operators would spend). --Krinkle (talk) 22:35, 15 May 2019 (UTC)
    Krinkle if we were to run a bot, why would we want the bot to look at Wikidata at all? The bot should directly watch for Commons category moves. I think most opposes would spot that, and see your proposal as motivated by serving Wikidata advocacy itself. Alsee (talk) 00:08, 19 May 2019 (UTC)
  • Oppose now; maybe later. I looked at a few examples from Category:Commons category link from Wikidata to see how well it works at the moment. I found Category:5 Kanal (Ukraine) where {{Commons category}} generates "Wikimedia Commons has media related to commons:Category:Kanal 5 (Ukraine)." Well, that turns out to be a redirect; the Commons category was moved and then merged in October 2018. This demonstrates that the Wikidata links are not currently being adequately maintained. Therefore we should not yet increase our reliance on them. Bots would be better employed in tracing and fixing errors such as that one. – Fayenatic London 09:39, 16 May 2019 (UTC)
  • Oppose The use of a template without a parameter is very confusing for new users who scratch their head wondering where the data comes from. We should be making things easy for users by making it clear what we are linking to and where the data is coming from. It gets even more confusing for uses where there is 2 templates in an article 1 with a parameter and 1 without a parameter. There is also the unreliability of wikidata entries and no visibility that there has been a change to the destination of a link, unless you are also watching wikidata changes on an article. Watching wikidata changes just adds to watchlist length and can cause the limit of 1,000 changes to be reached far to easily. Report differences in the entries by tracking categories (removing the tracking category that it is on wikidata). By the way I did not get either of the pings that this was taking place. Keith D (talk) 12:26, 18 May 2019 (UTC)
  • Late oppose per Kerry & Keith D. Happy days, LindsayHello 11:24, 31 May 2019 (UTC)
  • Support as admin on Commons and heavy Wikidata user. Pushing to the extreme, any interlink template should be deleted in every project as the "Commons" in the sidebar should be enough. The templates on en.wiki are often filled with obsolete / improper data (i.e.: commons categories which are not the right ones, or that have been redirected to a more appropriate name) and the bots that read those parametres import wrong data to Wikidata. Wikidata has been created to be a centralized archive, not as a double for data present on the other chapters and projects. -- SERGIO aka the Black Cat 13:18, 2 June 2019 (UTC)
  • Oppose - on the grounds that wikidata, whether reliable or not, is outside Enwiki editors view and any incorrect data, whether poor editing or vandalism or anything else, will be unnoticeable. Too much reliance on the external project for invisible functionality is dubious to my mind. GraemeLeggett (talk) 06:01, 15 June 2019 (UTC)

Discussion (Commons category links)

  • I think we have cases when one article has two commonscat templates pointing to two different categories. I suggest that these cases be kept. If there is only one commonscat template, I agree with the proposal to remove it. Whereas we do have vandalism instance at Wikidata, in which case the sitelink disappears or is invalid, we have way more cases of commonscat templates pointing out to redirects just because the Commons category was moved and the template has not been updated.--Ymblanter (talk) 18:24, 4 May 2019 (UTC)
    @Ymblanter: In cases where there are multiple commonscat templates in one article, this proposal would only remove the local text from the one that matches the sitelink. I can add an exception to avoid those cases if that's what we want to do, though. With that type of vandalism, that would be a cross-project problem to fix, and it would be caught by tracking categories both here and on Commons. Thanks. Mike Peel (talk) 18:39, 4 May 2019 (UTC)
  • @Mike Peel: FYI, I didn't receive your ping, and I assume the rest didn't either. Probably you've not signed the edit with the mentions. – Ammarpad (talk) 04:58, 6 May 2019 (UTC)
  • Request for example @Mike Peel: Can you provide an example where this proposal would change things? Can you talk through what the bot would check in that case to determine the need for a change? Blue Rasberry (talk) 13:55, 6 May 2019 (UTC)
    @Bluerasberry: For example, Category:2012 in the Maldives linked to commons:Category:2012 in Maldives, which was correct until the commons category was renamed. That was automatically updated on Wikidata, but required a bot edit here rather than updating automatically (as it would have if the locally defined text didn't exist). You can look through the edits of Pi bot to find many more examples like this. You can also dig through the other commons category tracking categories to find cases where the bot hasn't managed to catch it for some reason. The new bot would check for cases where the commons sitelink exactly matches the locally defined one, and would only remove it if that was the case. Thanks. Mike Peel (talk) 19:21, 8 May 2019 (UTC)
    I see, thanks. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)
  • When pulling from Wikidata, is there a link to the page where an edit may need to be made to correct the issue of a bad link (whether that's the same item or the category item)? --Izno (talk) 18:56, 7 May 2019 (UTC)
  • @Kerry Raymond: A sensible argument. If there were only the two sites, Wikipedia and Wikidata, then it could be said that Wikipedia, as the more active site, would be a good place to keep the data, since more people will monitor it. But consider: there are more than two sites. Besides the English Wikipedia, there hundreds of other Wikipedias, not to mention sister projects and all of their languages. Is English Wikipedia really the more active site for every page? Many of our pages are stubs, and some of those same pages are flourishing on other language editions. Wikidata is the natural central location to keep all of these links, so all of the Wikimedia family wikis can benefit from each others' work. ARR8 (talk) 00:34, 8 May 2019 (UTC)
    Is this RfC occurring on all Wikipedias and only proceeds if all WPs agree? This village pump can only decide policy for en.WP and not impose it on other Wikipedias and vice versa, so I don't see this as a relevant issue unless it's a global proposal. I don't have a problem with a Commons category being suggested based on information held in Wikidata but not to impose it. Kerry (talk) 02:01, 8 May 2019 (UTC)
    @Kerry Raymond: This RfC is enwp-specific, I'm not sure there's a good place to raise it globally across the different Wikipedias? But regardless of that, I'd contest that the 'ground truth' of this is now the sitelinks on Wikidata, not the locally defined text here. The sitelink is used on Commons to add the interwiki links to the various Wikipedias in the sidebar (the same as interwikis work here), and to display information from Wikidata about the topic of the category (through the infobox there). If that sitelink is wrong, then a Commons editor can fix it by editing Wikidata. However, that won't currently fix the link to the category from here, unless they also come to enwp to fix it, which they won't if it's a topic in a non-English country (I know you mostly edit about Australian topics, but think about editors that work on Portuguese or Spanish content both on their language wikis and on commons). Vandalism of the sitelinks is possible, but it's not trivial - you have to change the sitelink to point to a different, existing, category (compared with just changing some text in an article), so it's unlikely. For the cases that this RfC is concerned about, the information here is merely a copy that can easily go out of date. I'm out of energy to argue about your other points now, I'll follow up on them another day. Thanks. Mike Peel (talk) 19:39, 8 May 2019 (UTC)
    @Kerry Raymond:, well, at first Wikidata was used by everyone but en.wiki users, who seemingly didn't believe very much in that project at begin :-) BTW I can assure that, as Commons admin and 'Data heavy user, the use of parametres in Commonscat is annoying/problematic for the correct maintenance of the categories on Commons. I'll omit the cases in which commonscat links to a whole improper category (this or this, for example); but there are a lot of Commonscat templates filled with Commons categories that either no longer exist or have been redirected. It's not a mattere of data authority (anyway, as a matter of fact, Wikidata users have to reference data too, thus 'ground truth' is a false argument. If you have a solid source for the data migrated on Wikidata, include it in the property on the Wikidata item, there are fields created just for that purpose, and the chain won't be broken...). -- SERGIO aka the Black Cat 08:06, 3 June 2019 (UTC)
    The Commons category named in an en.WP article represents at the time it was asserted the current consensus of which Commons category(s) best correspond to the article content. I agree entirely that changes on Commons can take place without alerting anyone on en.WP interested in that article. I would welcome some system of notifications so such relevant changes correctly propagate through the notification system cross-project so the changes to the Commons category can be reviewed by interested en.WP contributers (and of course vice versa). This proposal increases the existing problem by additionally allowing changes on WikiData to silently override the intentions of contributors on local projects. Each project controls its content; where we have dependencies between the projects, we need to find ways to manage such dependencies. Just as WP articles may reference a Commons category, many Commons categories contain links back to a Wikipedia article to provide a description of the topic in a specific language, so often there is mutual co-dependency. Right now we don't have any agreed social or technical process to notify and resolve cross-project dependencies, but I would like to think consensus from all affected projects would be the overarching principle. This proposal (not being discussed on Commons or any other WPs which allegedly benefit from it) will bypass consensus on other projects by silently automating and implementing a decision made on Wikidata. Wikidata right now is full of bad modelling and inappropriate population of data based on the presence of a certain template. One that directly affects me is Queensland place ID (P3257) which has incorrect constraints and has been populated incorrectly, resulting in hundreds of constraint violations for which I have asked "to fix the problems on Wikipedia", but Wikipedia is not the problem here, the problem is on Wikidata, but nobody on Wikidata will take responsibility for fixing the problem. If Wikidata contributers had bothered to discuss with Wikipedia contributors who use these place IDs in articles in the first place (i.e. created a cross-project consensus), we could have avoided the problem. As far as I know, there may be ongoing automated processes continuing to make this problem worse (I create new Queensland place articles all the time). Imagine if someone said "let's transclude the value of the Queensland place ID held on Wikidata automatically into Wikipedia articles", we would trash thousands of article and their citations with bad data. How does such a proposal differ from this one? Both are based on the unquestioned assumption that Wikidata has it "right" (or at least "more right" than any other project); well, I am questioning that assumption. Nobody has explained how having copied and removed the Commons category from an en.WP article, what keeps that data safe on Wikidata (whether from vandalism or the result of poor-quality modelling/population as I illustrate above) resulting in erroneously changed values on Wikidata being silently transcluded back into a rendered Wikipedia article bypassing those people on Wikipedia who maintain that article. I am not anti-Wikidata in concept, but I have developed an increasing concern about what is happening in practice given the apparent indifference to quality modelling and quality "scraping" from other projects. We need a cross-project dependency notification system and once we have that, we have a better basis for the kinds of automated transclusions being proposed as contributors on local projects would be aware of it, just as if it was manually changed on that local project. Kerry (talk) 09:26, 3 June 2019 (UTC)
    I know what you mean, @Kerry Raymond: but Commons is everyday less and less dependent on en.wiki referencing, since there are templates like "Wikidata Infobox" or "Creator" that take data directly from Wikidata, and wikidata itself relies less and less on data imported from regional chapters (for example, all the data I upload on Wikidata come from reliable third party sources), and this will be the future of Wikidata: no longer a recipient of data collected from the local chapters but a centraliser of data collected from reliable sources. Further, consider that you can have on Commons a category on an item that doesn't appear in any Wikipedia, because Commons and Wikipedia have two different goals... -- SERGIO aka the Black Cat 08:49, 8 June 2019 (UTC)
First, I note it has not been raised on Commons:Village_pump/Proposals and that's just one place, but if the benefits are for all WPs as sugggested above, surely all WPs should be in this conversation. Kerry (talk) 23:22, 8 May 2019 (UTC)
Second, I don't think you understand what is meant by "ground truth", which Wikipedia defines as "information provided by direct observation (i.e. empirical evidence) as opposed to information provided by inference". In science, the ground truth is the laboratory notebook; you never destroy them, just because the information has been copied elsewhere, because in the event of questions/dispute, you always go back to the lab notebook. When it comes to Commons categories, the ground truth is the decision/consensus of editors on Wikipedia. Are you seriously proposing that Wikidata editors should decide from now on which Commons categories should be added to a new article and not Wikipedia editors? How will it work in practice? Let's say I have an article on the Marian sugar mill which has its commons category set as Category:Sugar mills in Queensland. Let's say someone takes a lot of photos of that mill and creates a sub-category on Commons called Category:Marian sugar mill, which is a better commons category for the article to use. Who will update it and how? A Wikipedian do so by updating the template in the Wikipedia article to add the new category, or will they be forced to go to Wikidata to do this? Can we have this proposal spelled out for the whole lifecycle please, currently all it deals with is taking existing information away from Wikipedia and does not explain what happens next, how updates will be oversighted, how and where disputes will be conducted. If we go down this path, I think we need Wikidata watchlist notifications that affect the Commons category to be propagated through into the watchlists of Wikipedia articles (on all WPs) that are affected by it. Not *all* Wikidata updates to the Qnumbered thing, just the ones affecting Commons category. If the watchlist situation can be resolved and the ability to update the Commons category locally from Wikipedia (and not having to learn anything about Wikidata), then I would be much less worried. Because who on Wikidata is putting their hand up to watch the Queensland sugar mill edits that I would normally watch on Wikipedia? And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. Kerry (talk) 23:22, 8 May 2019 (UTC)
@Kerry Raymond: I'd be happy to point this proposal out on Commons and elsewhere, but then I'd probably be accused of WP:CANVASS. :-/ With most of what you say, substitute 'Commons' in place of 'Wikipedia', and it changes the perspective. The point is that Commons editors also play an important role in linking Wikipedias<->Commons, and using Wikidata to do this in one place is a lot better than doing it in multiple places. I'm not proposing to remove the ability to set a local link here if needed, so in the example you give you could still define that manually, I just propose to remove the duplication of exact data. There are over 2 million commons sitelinks now, and the 600k or so here is just a subset of that. Thanks. Mike Peel (talk) 06:08, 9 May 2019 (UTC)
It's only canvessing if you do so in a way to influence someone and, yes, the RfC as written does run that risk as it is supposed to be written to be NPOV. So rewrite the RfC to be NPOV and then advertise it on other sites that it affects. Kerry (talk) 07:20, 9 May 2019 (UTC)
In practice, I see a lot of Commons categories which were set here on the English Wikipedia long time ago and then moved on Commons. Our template leads nowhere (or sometimes to a category redirect) because nobody cared to go here (and to 200 other Wikipedias) and update the commonscat template. However, if a category has been moved on Commons, the record has been automatically updated on Wikidata, and the sitelinks in the same articles are usually correct.--Ymblanter (talk) 15:00, 11 May 2019 (UTC)
Oh, I see, Mike Peel has already made above the same point.--Ymblanter (talk) 15:02, 11 May 2019 (UTC)
@Ymblanter: It's a good point, worth repeating. :-) A lot of the work I've been doing here recently has been to try to fix these (by bot/manually), but it takes time, and it would be better if the problem didn't exist in the first place, hence this proposal. I hope you consider !voting on it. Thanks. Mike Peel (talk) 15:38, 11 May 2019 (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 concerning padlocks

This is based partly on my own experience, but regardless I think it has merit. When a registered and qualified Wikipedian logs in to a semi-protected article, or any other relevant protected article, for that matter, I would like to see the padlock/s automatically disappear. That would make it clearer, (especially for newbies) in my opinion. Obviously, it would not apply to registered and unqualified or unregistered users. Editrite! (talk) 02:26, 22 June 2019 (UTC)

Let's say a suitably-privileged user adds a padlock to a protected page. How would they test that the padlock was actually being displayed? --Redrose64 🌹 (talk) 20:00, 22 June 2019 (UTC)
Should be doable via gadgets/scripts or something, but it's not something that should be on by default. Headbomb {t · c · p · b} 21:01, 22 June 2019 (UTC)
But an editor can already find out whether they can edit a page by the state of the Edit button (for example whether it says "Edit" or "View source"). However, if an editor wants to find out whether a page is protected, how are they going to do that if the padlocks are invisible to them? – Uanfala (talk) 22:24, 22 June 2019 (UTC)
In answer to both Redrose64 and Uanfala, the padlock/s ONLY disappear when you LOG IN, so in other words, when you log out they will automatically reappear, or alternatively they will appear BEFORE you log in, as if you were unregistered. It's true that there is an Edit button but here's the thing. When I registered and qualified as an editor, because the padlock was still displayed on protected articles after logging in, I mistakenly assumed that meant I was still not allowed to edit. Hence my proposal to avoid ambiguity. I doubt that I was the first, or will be the last to experience this situation while the padlock remains all the time. Editrite! (talk) 05:11, 23 June 2019 (UTC)
If a page is protected, a padlock icon can only be added by a person who has the matching (or higher) editing right, and logged out users have none of these rights. Imagine that somebody locates a page that is protected because of vandalism, but has no padlock. They log in (if not logged in already) and add a template like {{pp-vand}} to the page. But nothing then displays, because you (Editrite!) don't want that person to see anything. They then think that they made an incorrect edit, and remove it again. Nothing is solved. --Redrose64 🌹 (talk) 13:54, 23 June 2019 (UTC)
I honestly wouldn't put this as a high priority for implementation or even discussion. But we could display a locked padlock for users that do not have the required rights, and an open padlock for users that have. And no padlock for unlocked pages... --Stephan Schulz (talk) 14:17, 23 June 2019 (UTC)
1. Mouseover the padlock and it explains that the article is protected. It doesn't say that the article is protected from you. Use information resources that people have gone to some effort to provide you, and you will be less likely to "mistakenly assume". 2. In real life, padlocks don't disappear for those who have a key. 3. We generally require a demonstrated cost-benefit case, which means evidence that a proposed change would save editors enough time or mental energy to justify the cost of the change. We don't mistakenly assume that all editors are like us. ―Mandruss ☎ 14:48, 23 June 2019 (UTC)
I wouldn't put any priority on this except as an opt-in user script. The padlocks are to convey information about the protection levels of the article. I'm a template-editor, but knowing if a template is unprotected, semi- or template-protected is still useful because it lets me know who else can or can't edit the template. Same for articles. Headbomb {t · c · p · b} 16:38, 23 June 2019 (UTC)

Some of the comments that I have received here are bizarre, to say the least, for example comparing online with "real life". Are you serious? They show that you didn't read, understand or even worse still, distorted what I said. The only issue here, if there is an issue is cost. The software gurus shouldn't have any trouble coming up with an answer quickly, but in the unlikely event that they can't and it's not viable, (Wikipedia being a non-profit organisation) then obviously it's not a proposition. No system is perfect. The subject of vandalism is always a problem, and no matter what you do, you can only minimise it not eliminate it. As for the assertion that it's only for my benefit, or "assume that all editors are like us", nothing could be further from the truth, and I've made that clear. If you can't or won't see the bigger picture, then I can't help that. Just to be clear, what I am proposing is that ONLY while you are logged in to a semi-protected or protected article, as a registered and qualified user, will the padlock not appear i.e. it's only temporary. When you are not logged in, or you have logged out it will appear as normal, so it's easy to tell if it's protected or not. Editrite! (talk) 06:04, 24 June 2019 (UTC)

Calm down. People understand what you're proposing but disagree that it's a good idea. The fact that a page is protected is important information. For example our protection policy states that "Protected pages may not be edited except to make changes that are uncontroversial or for which there is clear consensus" so as an admin I need to know if a page is protected before I try to edit it.
Nonetheless, if you insist this feature is useful to you it can be done with a single line of javascript added to your common.js file:
if ( mw.config.get('wgIsProbablyEditable') ) { $('[id^=mw-indicator-pp]').hide(); }
the wub "?!" 13:19, 24 June 2019 (UTC)

@thewub Thanks for your input. There seems to be a perception that my proposal is for purely selfish reasons, but that's not how I operate (it would have been useful as a newbie to avoid confusion which was the point I was making, but not now). I'm more interested in constructive suggestions that benefit others. Nevertheless, I am willing to accept your interpretation that the handful of contributors here do not agree with my proposal at this time, and leave it at that. It's a pity . . . but that's life. Editrite! (talk) 22:56, 25 June 2019 (UTC)

Display A class as a top icon

Withdrawn as A class may or may not be better than a GA depending on each project's handling. NoahTalk 12:27, 26 June 2019 (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.

Currently, we only display two article qualities as top icons... GA and FA. I propose we change this and show A-class as well. My reason behind this is that A-class articles are inherently better than a GA. A-class basically approaches FA but falls just short. Considering A-class has multiple reviews that are likely more thorough than what it received at GAN (if it went through the process), I see no reason why we shouldn't display a top icon on A-class articles. NoahTalk 16:06, 24 June 2019 (UTC)

"Inherently better" Not really. A-class is not required to be reviewed by the community and is not generally required to have more than one reviewer. Maybe this is something to discuss on WP:VPI instead, but I do not think it will be likely to be accepted by the community. --Izno (talk) 17:36, 24 June 2019 (UTC)
@Izno: Well... maybe we need to discuss implementing a hard process for A-class articles. According to the current A-class criteria, it must be reviewed by at least 2 impartial reviewers. Would it be okay to just move this whole section over to the idea lab then? NoahTalk 17:49, 24 June 2019 (UTC)
Hurricane Noah, Some WikiProjects already have one, such as Wikipedia:WikiProject_Military_history/Assessment#ACR. Adam9007 (talk) 19:06, 24 June 2019 (UTC)
@Izno: A-Class is inherently better, at least in the sense that it's a higher grading than GA. It makes little sense to skip a grade with top icons. – Finnusertop (talk ⋅ contribs) 11:42, 25 June 2019 (UTC)
Uh, no. A and GA are strictly unrelated. One is a WikiProject grading and one is a Wikipedia grading, and the requirements for each differ accordingly. --Izno (talk) 13:47, 25 June 2019 (UTC)
Izno, Then the grading table needs changing. Anyone reading it would think that A-class is a step above GA. Adam9007 (talk) 00:37, 26 June 2019 (UTC)
@Adam9007 and Izno: If you even look at the main content assessment page, an article is not complete until it reaches A-CLASS... GAs may have weak areas according to one of the description boxes while an A-class is a nearly complete rendering that will leave non-experts wanting no more. Therefore a GA is an incomplete article, while an A-class article is. That means that A-class is above GA. NoahTalk 01:09, 26 June 2019 (UTC)
  • Support Per nom. For the few WikiProjects that actually do A-class, it's listed a grade above GA and has a higher standard and articles go through more scrutiny. It thus makes no sense to display a badge of honour for GAs but not for A-class articles. The only problem with this is that an article can be part of a WikiProject that does A-class and another WikiProject that doesn't. Perhaps being A-class one of the applicable WikiProjects would be enough to display the badge? Adam9007 (talk) 18:57, 24 June 2019 (UTC)
  • Support. Our current practice of skipping a grade with top icons makes little sense. A-Class is definitely a badge of honor, not shame, as the process is quite rigorous and results in quality content. – Finnusertop (talk ⋅ contribs) 11:48, 25 June 2019 (UTC)
  • If we want to use bold, oppose. Supporters are under some misapprehension about how these rankings interrelate. If they personally are interested in knowing what the class is without visiting the talk page, there's a gadget for that. --Izno (talk) 13:48, 25 June 2019 (UTC)
    Izno, By that logic, we should do away with having GA and FA top icons. I can't see that ever happening... Adam9007 (talk) 23:38, 25 June 2019 (UTC)
    I have corrected the misapprehensions above. If you are interested in responding to what those misapprehensions might be, above is the correct place so that we don't split the discussion. --Izno (talk) 00:25, 26 June 2019 (UTC)
  • Oppose. A may be placed between GA and FA in the table at WP:ASSESS, but I don't see them forming a strict hierarchy. For example, if you look at the criteria at WP:ACLASS, you'll find that they're not a superset of WP:GACR. Also, A/B/C grades are assigned by Wikiprojects. How they determine those grades is basically up to the individual Wikiproject. GA/FA are determined by independent editors following a very well-defined process (they also have well-defined processes for reviewing/revoking the status after it's been given). Also, even if you could fix the A criteria/processes such that they were clearly comparable to GA/FA: I don't see the need for another level of granularity. The difference between GA and FA is not huge. And for a casual reader, grokking the difference between GA and FA is probably already confusing enough. Colin M (talk) 23:31, 25 June 2019 (UTC)
@Colin M: If the difference isn't that great, why don't we just abolish A class entirely? Why not abolish B class while we are at it since there isn't much difference between it and GA? If you read the difference between GA and A, you will see there is a decent gap there. A GA may still be incomplete and lacking in areas while an A-class is required to be a nearly complete treatment of the subject. There are some GAs that are absolutely horrible and would warrant a withdraw if submitted for a FAC. The wikiprojects that actually do A-class reviews (makes up at least a majority of the current A-class articles) do a pretty good job at it. I'm pretty sure quite a few projects review according to FA standards as well. To say A-class is worthless and there isn't much of a difference just means you haven't gotten a lot of experience with those processes under your belt yet. I have gone through the GAN process several times and have two incumbent FAs. Trust me when I say there is quite a large difference. NoahTalk 00:50, 26 June 2019 (UTC)
  • While I might be misunderstanding something, from what I understand A-Classes are assessed by WikiProject and thus subject to local whims, so what may constitute A-class in one WikiProject may not be so for another. This is in contrast to FACs, which are assessed by a project-wide panel, and GANs, which have universal criteria. While I won't adamantly oppose this proposal I am skeptical of it, especially if one WikiProject assesses it as A-class but other relevant WikiProjects either don't have such a mechanism or view it only as a GA or even lower. (I've also never quite grasped the concept of A-class in general; from what I understand it's something in between GA and FA, but I've never really gotten how that works or what the criteria are as opposed to either respective grade. That is irrelevant here, though.) – John M Wolfson (talk • contribs) 06:31, 26 June 2019 (UTC)
@John M Wolfson: A discussion needs to take place for either the refinement or abolishment of A-class based on arguments above. I am archiving this as it is clear said discussion needs to take place before this. NoahTalk 12:26, 26 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A new use for Wikidata external IDs in Wikipedia (template)

I would like to propose a new template which would make a more visible use of the external identifiers contained by Wikidata. Similarly to Authority control and Taxonbar, it would collect the IDs leading to pages which expand on the subject with additional text (so not only data) like encyclopedias, biographies, etc. This would create a condensed portal to trustworthy sites and could:

  • encourage further reading
  • propagate and show reliable sources
  • make Wikidata more visible
  • add depth to article stubs, help finding sources for expanding them

Visually, I would imagine that the template could follow (or be part of) the infobox or it could be a sidebar next to the External links section. It could also be set as default to the language of the Wiki it is used in so in the German Wikipedia it would only list (or prioritise?) German language sites.

Two examples for what the template would contain (here without the language setting):

From the side of Wikidata I think it would require:

  • labeling external IDs according to content type (new property)
  • labeling language of external IDs (mostly done)

From the side of Wikipedia:

  • template coding, design
  • documentation of the template

What do you think? Please also indicate if you would like to help in the development. - Adam Harangozó (talk) 13:04, 9 June 2019 (UTC)

  • Mixed opinion - I have no problem with templates that export data from Wikipedia TO Wikidata... I continue to oppose templates that would automatically import data FROM Wikidata. I see no benefit to our project in this proposal. Blueboar (talk) 13:15, 9 June 2019 (UTC)
    Does it follow that it takes use cases that show how Wikipedia will benefit from data FROM Wikidata or is it just that you are against? Thanks, GerardM (talk) 17:31, 9 June 2019 (UTC)
    Blueboar, if you see no benefit for Wikipedia readers to get curated links to high-quality third-party sources, then perhaps the problem is your vision, and not Wikidata? --Magnus Manske (talk) 08:35, 10 June 2019 (UTC)
    I see great benefit to including curated links... but the curation has to be done manually, here on WP... not automated through WD. Blueboar (talk) 11:14, 10 June 2019 (UTC)
    What makes you think curation on WD is "automated"? There are certainly more bots and tools involved, but mostly because WD is easier to edit through those. Tools like Mix'n'match do a combination of manual and automated (where highly reliable) curation. Claiming WP is, overall, better at curation is insulting at best. --Magnus Manske (talk) 14:05, 10 June 2019 (UTC)
    You miss the point... the curation needs to be done HERE on WP... not at WD. Blueboar (talk) 14:28, 10 June 2019 (UTC)
    The first round of curation is done on Wikidata: already the fact that there is a property for that external ID means that there was a consensus about its importance. Also, if we label it there as having descriptive text is another round of filtering. After this the export would be automatic but I think there should be an option to manually exclude IDs from the template in the article. Adam Harangozó (talk) 17:54, 11 June 2019 (UTC)
    ”The first round of curation is done on Wikidata”... exactly... that is what I object to. Blueboar (talk) 22:30, 18 June 2019 (UTC)
  • Oppose any further automatic import from Wikidata. To pick up Magnus Manske's phrase, the problem is that a lot of links in Wikidata are not curated links to high-quality third-party sources. The "curation" is far less than here, as there are far fewer active editors. There's isn't the body of long-established and widely discussed policy which defines what a "high-quality third-party source" is, as opposed to the policies on sourcing here. Peter coxhead (talk) 09:07, 10 June 2019 (UTC)
    I protest this (deliberate?) mis-quote. The display of WD data on WP would be automated. The curation on WD is a mixture of manual (as here on WP, but with better tools) and automated (where highly reliable). Please change to Support, or remove me as your reasoning. --Magnus Manske (talk) 14:08, 10 June 2019 (UTC)
    I believe that most of the external IDs collect reliable sources but even if there are exceptions this could be sorted out when labeling their content type on Wikidata and any problematic source could be removed manually from the template later. An overview of some of the sites that are being worked into WD (here only the biographies): https://tools.wmflabs.org/mix-n-match/#/group/biography Adam Harangozó (talk) 18:05, 11 June 2019 (UTC)
  • Support: I believe this is an important step towards the main goal of Wikidata: to feed sister projects with structured data. --Hjfocs (talk) 09:08, 10 June 2019 (UTC)
  • Support: but with a couple of caveats. Number of external IDs (too much ?), language of external IDs (Russian or Italian less helpful in WP-En), probably this project would benefit from some design and curation work on the WD side. Kpjas (talk) 09:24, 10 June 2019 (UTC)
    • probably this project would benefit from some design and curation work on the WD side – yes, but that's the problem for me. Who is going to do this work? Consider {{Taxonbar}} as an example. This template is now present on the great majority of articles about organisms. My experience is that when I create a new organism article (I mostly work on plants and spiders), on average I have to spend quite a bit of time (perhaps one third to half the time to create a "Start" class article) fiddling with Wikidata items to get the taxonbar to work as it should in our article – and quite often it's not entirely possible, because the design principles of Wikidata are not compatible with ours (e.g. insisting on 1:1 relationships between wiki articles and Wikidata items, when this is not how it actually is). So the odds are that if the curation of Wikidata were done well, it would involve considerable continued input from editors here, which distracts from the main goal of building an English language online encyclopedia. If there were lots of receptive editors at Wikidata, open to discussions, it would be a different matter. But that's not my experience. Peter coxhead (talk) 10:06, 10 June 2019 (UTC)
      • I really think this could be more constructive. Of course there might be issues but WD are WP are for each other not against. The 1:1 relationship would work with articles about individual people, and the others we might need to work on more - from both sides. Also, please check Elmidae's opinion below. Adam Harangozó (talk) 18:22, 11 June 2019 (UTC)
    • The number of IDs shown is a design question regarding the template on Wikipedia (sidebar, navbox, collapsing, etc.). The languages have to be tagged in Wikidata but as I said I think the template should only show IDs that are in the language of the WP article. (This would also keep the numbers at bay.) Adam Harangozó (talk) 18:22, 11 June 2019 (UTC)
  • Oppose per Peter coxhead. This scope creeping by Wikidata aficionados needs to stop and they need to get their own house in order. We have enough maintenance problems here without importing more from somewhere else. - Sitush (talk) 10:50, 10 June 2019 (UTC)
  • Neutral middleground Hi all, there is a grant project that could help out here called GlobalFactSync (GFS). The major problems are: (a) On the one hand, Wikidata is not considered good enough yet to be imported into WP-EN, so GFS tries to sync all info from WP-EN into Wikidata to improve it. (b) On the other hand, Wikidata is used in exactly the proposed way in the Italian Wikipedia, see Usain_Bolt#Collegamenti_esterni GFS just started, but discussion as such seem very relevant. We are looking for 10 concrete sync targets. One will be the domain of Albums/Singles with MusicBrainz. So another one could be the links to the external sites mentioned above. The goal is to improve Wikidata in these sync targets to a level that meets WP-ENs standards and then make it much easier to maintain, so quality stays better than now and work becomes less. GFS just started, so we will still need good feedback. SebastianHellmann (talk) 12:08, 10 June 2019 (UTC)
  • Support. Please inform yourself about Wikidata before tossing a vote because you heard your buddy say "WD is bad". Don't make this another Brexit referendum; there, it was all the EU's fault... --Magnus Manske (talk) 14:11, 10 June 2019 (UTC)
  • Support. Indeed a good idea and it is definitely too simple to claim one wiki project to have in general beetter quality than another one it just depends on the topics and often just the individual item or article. Unfortunately users tend to see the projects they are deeper involved with in a much more positive way than other projects they are less involved in. Robby (talk) 16:22, 10 June 2019 (UTC)
  • Weak support I share the concerns about the reliability and curation of Wikidata. This does not reflect on the work of the editors on that project, but on the fact that there are so many fewer eyes on harder-to-curate material. For most purposes, WD import into WP still seems like a dangerous proposition. - Having said that, this particular proposal sounds largely innocuous to me. As with WP, the main issue with misleading material in WD is statements that are not backed up by sources. Bypassing any import of statements and directly linking to sources avoids this step (and it is the step where shit mostly happens, if it does); and readers must always be capable of assessing sources for themselves. This would in effect work like an extended "External links" section, and probably of overall better quality than that. --Elmidae (talk · contribs) 18:04, 10 June 2019 (UTC)
  • Too soon to ask. I think this proposal, while well-intentioned, needs some more workshopping before we can come to a reasonable conclusion. For example, is the proposed new property of external ID content type something that Wikidata wants, and how will this be implemented? What types of IDs would we import and what types would we exclude? What happens if someone disagrees about importing a particular ID? Will it be possible to exclude it on the article level, on a more global level? Would there be overlap with the existing {{authority control}}, which already imports some external IDs from Wikidata? How will this proposal interact with WP:EL? Will there be a max number of links imported? For the moment until some of these questions are answered I will oppose the proposal, but I'd encourage some more work in conceptualization with an eye to a future proposal. I'd also expect that such a template would need a broad RfC before widescale implementation. Nikkimaria (talk) 00:51, 11 June 2019 (UTC)
  • Support per many of the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 12 June 2019 (UTC)
  • Oppose would directly violate WP:EL - which requires external links are justified on-wiki on their merits. A template drawing through whatever Wikidata is deciding to host today doesnt fulfil our editorial criteria. Most of the examples above would fail point 1 of WP:ELNO. As an aside two of the links above triggered my virus scanner for malware/popup-ads. Only in death does duty end (talk) 21:30, 12 June 2019 (UTC)
  • Oppose. The issues I list below range from "difficult" to "effectively impossible" to resolve, and the list clearly incomplete:
    • Wikidata content is not subject to Wikipedia policies and guidelines, including but not limited to WP:EL. Challenged External Links are removed and stay-out unless there is an active consensus for inclusion.
    • Any such content needs to be administered on Wikipedia.
      • Even non-autoconfirmed editwarrior or vandal can go to Wikidata and BYPASS Full page protection. An IP editor could even bypass Superprotect (if it were redeployed). This is a fundamental design problem with Wikidata integration.
      • Page protect at Wikidata can prevent us from repairing policy violations on our articles, even if Nazism or pedophilia related content is maliciously placed on the biography of a living politician.
      • It bypasses our editfilters and link blacklists.
    • Any such content needs to be curated on Wikipedia.
      • It's impossible to find (and potentially clean up) these links, as they don't show up in search results.
      • A significant number of editors here are are uninterested or unwilling to go to Wikidata to edit.
      • It makes things more difficult for new users - and even for many experienced editors. The content magically appears in the article, and it can be confusing to figure out where the hell it's coming from. And once you do find where it's coming from, Wikidata imposes a different and potentially confusing interface that is (in my experience) functionally deficient. To anyone who is happy with Wikidata and the Wikidata interface: Good for you. Not everyone agrees with you, and it creates an additional and unnecessary hurdle for those who don't agree with you.
    • The majority of Wikidata edits are essentially a bot-farm, with some human edits intermingled. Note: Wikidata "editor" statistics are wildly inflated. For example when a page tracked by Wikidata is moved, that edit gets mirrored as a Wikidata edit by that user.
    • We really don't need the headaches of cross-language editwarfare. In particular, there's currently major drama at Meta involving a language-wiki where essentially the entire admin corp are waging "information warfare" of genocide denialism. Note that Google Translate for the language is abysmal and often reverses the meaning of a sentence, making any sort of discussion almost impossible. Alsee (talk) 07:22, 16 June 2019 (UTC)
    • The huge RFC on Wikidata-in-infoboxes ended with approximately half of the community wanting Wikidata gone from infoboxes. We should not be rolling forwards major Wikidata integration until we can reach some consensus on whether we want to keep or eliminate the existing integration. Alsee (talk) 07:22, 16 June 2019 (UTC)
    • Again: The proposal is for links to a set of sites curated here on Wikipedia, much as is already done in {{Authority control}} or {{Taxobar}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:57, 18 June 2019 (UTC)
  • I love the idea of using Wikidata more on Wikipedia. I've read through your proposal a few times, and I'm not really sure exactly what it is you're proposing; could you produce a few mockups to illustrate your idea? --Deskana (talk) 21:15, 16 June 2019 (UTC)
  • Support.--Vulphere 05:52, 27 June 2019 (UTC)

Wikipedia homepage

I am proposing that on the WP homepage, that Italian and Polish be swapped with Hindi and Arabic because these languages are more widespread. Interstellarity T 🌟 01:37, 29 June 2019 (UTC)

This is handled by Project portals and not something within control of the English Wikipedia. There's some info there about how it's structured and who maintains it. Killiondude (talk) 02:04, 29 June 2019 (UTC)
Killiondude, Where can I propose the change? Is there a talk page I can go to to do that? Interstellarity T 🌟 11:05, 29 June 2019 (UTC)
@Interstellarity: If you're talking about www.wikipedia.org, the languages change dynamically. I don't recall what the logic is that selects the defaults, but, if you've expressed a preference for a language in your browser, then the portal will alter which links it shows to include that languages. If you express multiple ranked language preferences (which most modern browsers support), then the portal will change the links to display as many of those languages as possible. --Deskana (talk) 22:29, 29 June 2019 (UTC)
For the most part @Interstellarity: you can theoretically change this: www.wikipedia.org generally lists the top wiki's by number of articles, so get more articles in the other languages and they will move up the priority list. — xaosflux Talk 23:26, 29 June 2019 (UTC)
@Xaosflux and Deskana:, The Swedish and Cebuano Wikipedias have a lot of articles, but they are not listed on the languages circling the Wikipedia ball. Is there a reason behind this? Interstellarity T 🌟 23:44, 29 June 2019 (UTC)
Like I said, "for the most part". There is a long story about cebwiki's 5million+ "articles" - a huge (controversial) bot dump of machine created articles was done at cebwiki,svwiki, and warwiki (see Special:CentralAuth/Lsjbot) so these aren't really counted along with actual human-produced articles for that page. — xaosflux Talk 23:54, 29 June 2019 (UTC)
See also meta:List_of_Wikipedias for a list of all the various language wiki's by size. — xaosflux Talk 23:57, 29 June 2019 (UTC)
Xaosflux, There's probably not much I can do at this point so I won't bother discussing the issue at the point. Interstellarity T 🌟 00:15, 30 June 2019 (UTC)
The top ten are actually set by how many page views each language project gets (unless the user's browser language preferences indicate that some particular language(s) might be preferred). --Yair rand (talk) 23:40, 30 June 2019 (UTC)

Proposal: Renaming Wikipedia:Village Pump

WP:SNOW. There's no chance. – Ammarpad (talk) 15:54, 1 July 2019 (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.

Simple suggestion - A proposal to have Wikipedia:Village Pump to be renamed to Wikipedia:House of Wikipedia — Preceding unsigned comment added by Regice2020 (talk • contribs) 18:59, 29 June 2019 (UTC) Having it named Village pump sorta indicates small amount come here, but having it named House this can match million for people who used Wikipedia to edit. Regice2020 (talk) 19:03, 29 June 2019 (UTC)

Support or Oppose

Clearly @Mandruss: is the person to know - can I come stay in your 1000 person house? Nosebagbear (talk)
Obviously a terrible idea- "Wikipedia:City Center" is the only logical title⸮ TheAwesomeHwyh 00:29, 1 July 2019 (UTC)

Comments

(after edit conflict with another editor making an identical edit to that which I was trying to make) Why? Phil Bridger (talk) 19:05, 29 June 2019 (UTC)

In response to the original poster's explanation, a village pump is precisely the kind of place where everyone has to go. How else would you get any water? "House of Wikipedia" sounds like a royal dynasty or a department store, both things that many people, such as me, would rather avoid. Phil Bridger (talk) 19:11, 29 June 2019 (UTC)

Before changing anything in an established system (such as Wikipedia) you should first establish that there is a need for a change, such as the existence of a problem that requires a solution. So: where is the need for change? --Redrose64 🌹 (talk) 19:20, 29 June 2019 (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.

End the Signpost

WP:SNOW Interstellarity T 🌟 11:38, 3 July 2019 (UTC) (non-admin closure)

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.

Should Wikipedia:Wikipedia Signpost be discontinued? wumbolo ^^^ 20:11, 2 July 2019 (UTC)

Survey (End the Signpost)

  • Yes. Many have asserted that editorial changes would solve disputes, but the team of editors keeps getting worse and the harassment more vicious. I love reading old Signpost articles, but I believe that it has become a net negative and a waste of time. wumbolo ^^^ 20:11, 2 July 2019 (UTC)
  • No The Signpost (for which I volunteer) is not only the editing community's best news source for the Wikipedia movement, it is one of the best collators of community sentiment, helping all to understand where we collectively sit. Especially now, under the dictates from a distant home OFFICE, a sense of collaboration and community is key. Wumbolo, a non-contributor upset about perceived sleights, wants to kill what little community conversation we have outside massive RfCs and talk page discussions. Chris Troutman (talk) 20:19, 2 July 2019 (UTC)
  • No. This request by Wumbolo is insufficient because he cites the editorial board (for which I am a member) as the problem. My apologies to Wumbolo for any distress that our coverage has caused, but I'm not exactly empowered to change the direction of the Signpost here. I wasn't even involved with the last issue nor do I even have the influence or control to make publishing decisions. No offense to Smallbones, but the paper is currently structured to run like a benevolent dictatorship à la Leviathan. Our people are great, but our structure is what's lacking. –MJL ‐Talk‐☖ 20:34, 2 July 2019 (UTC)
  • No but the culture there needs to change (see [1] in particular), big time, and become much less of a walled garden. The Signpost has a purpose, and publishing mockery, anonymous allegations, and BLP violations is not part of it. Headbomb {t · c · p · b} 20:34, 2 July 2019 (UTC)
  • No Wumbolo has failed to present evidence that The Signpost is a net negative. Cullen328 Let's discuss it 20:36, 2 July 2019 (UTC)
  • Not yet. The Signpost needs to stop pretending Gamaliel and others didn't happen and stop pretending that policy doesn't apply to them, but there's still a legitimate function for it. ‑ Iridescent 20:37, 2 July 2019 (UTC)
  • Not Never One of my favorite things about Wikipedia. More please. -- GreenC 20:58, 2 July 2019 (UTC)
  • Not quite time: In my view, The Signpost has its issues: it seemingly always manages to inflame and infuriate its readership; the editor-in-chief needs to consider their words and actions long before the newsletter goes to press; and the culture over there needs serious change in light of Headbomb's good suggestions. Having said all that, however, I believe it serves its function as an internal newsletter quite well. For now, it should remain. —Javert2113 (Siarad.|¤) 21:20, 2 July 2019 (UTC)
  • No. They are trustworthy and I enjoy their reporting. Anne drew (talk) 21:29, 2 July 2019 (UTC)
  • No - No reason has been provided, and we shouldn't delete something all because of one silly report. –Davey2010Talk 21:45, 2 July 2019 (UTC)
  • No. It may need a bucket of cold water thrown over it, and some extra heads to restrain some of its excitability ... but while its's not as good as in the old days, it remains a net positive. --BrownHairedGirl (talk) • (contribs) 23:51, 2 July 2019 (UTC)
  • No What is it about Wikipedians, babies and bathwater? Triptothecottage (talk) 23:56, 2 July 2019 (UTC)
  • No. The current issue around the Signpost is 100% fixable, and is only one case out of many that have gone otherwise fine. --Masem (t) 00:02, 3 July 2019 (UTC)
  • No There wouldn't be anything left of Wikipedia if we applied such a "nuke it because there is a problem" reasoning rather than "fix it because there is a problem". Meters (talk) 03:54, 3 July 2019 (UTC)
  • No a clear overreaction to this situation. MarnetteD|Talk 04:02, 3 July 2019 (UTC)
  • No. You dont burn a house down because there is a crack in one of the supporting columns but fix it. CASSIOPEIA(talk) 04:22, 3 July 2019 (UTC)

Discussion (End the Signpost)

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: To make it clearer that there are multiple Wikipedias (for several different languages), note the Wikipedia's language in the title logo for each Wikipedia

Many, if not most, users seem to have an incorrect mental model of what Wikipedia is. They seem to think that it is a single global encyclopedia, encompassing all of the world's languages. When users navigate to Wikipedia, they automatically go to the Wikipedia for the particular language that their computer is configured for, and therefore they often don't realize that there are actually multiple Wikipedias, one for each of several of the world's languages.

Why is this a problem? If a user has a mental model of a single Wikipedia that encompasses all of the world's languages, then they may get frustrated or angered by a Wikipedia page that uses a spelling in the particular Wikipedia's language, rather than in the topic's language of origin (if it's different). They may think that Wikipedia is appropriating, belittling, or ignoring the topic's language of origin. This is especially true for the English-language Wikipedia (as it is so comprehensive, and includes many topics about subjects whose names in English are different from the name in its language of origin). Users often do not understand that - being the English-language Wikipedia - article titles generally use the common spelling/usage in English - i.e., WP:COMMONNAME.

Proposal: Note each Wikipedia's language prominently near the top of each page. For example, change the text of the Wikipedia logo from:

Wikipedia
The Free Encyclopedia

to

English-language
Wikipedia
The Free Encyclopedia

(and similarly for other languages' Wikipedias). Ross Finlayson (talk) 05:22, 29 June 2019 (UTC)

No. That's just superfluous. All Wikipedia logos are already localized to the language of the wiki. If you go to the French Wikipedia https://fr.wikipedia.org, the logo reads in French Wikipédia, L'encyclopédie libre, the text is not even in English so it borders impossibility to be confused on which language domain one is unless you don't understand the language. Localization is more than any translation to tell you now you're on a xxx-language Wikipedia. You know it by mere seeing if you understand the language. The same thing goes for all other language versions. See m:Wikipedia logo in each language. – Ammarpad (talk) 05:57, 29 June 2019 (UTC)
I think you misunderstood what I said; please read it again. I never said that a user is confused about which language 'their' Wikipedia (i.e., the one that they're taken to, based on their computer's language preference) uses. What I said is that users are often confused about the fact that there are multiple Wikipedias (for multiple languages). Noting each Wikipedia's language prominently near the top of the page would help do this. There might be better solutions, though. Ross Finlayson (talk) 06:34, 29 June 2019 (UTC)
I don't know if it is often but it definitively happens. Gråbergs Gråa Sång (talk) 10:36, 29 June 2019 (UTC)
  • If we had a tag saying "Wikipedia - the Free English language encyclopedia that any one can edit" - would there not be a danger that this might make some readers think that Wikipedia is only available in English? Vorbee (talk) 14:49, 29 June 2019 (UTC)
Perhaps the tag should say: “Wikipedia(En) - one of several Wikipedia brand encyclopedias - that anyone can edit.” Blueboar (talk) 15:26, 29 June 2019 (UTC)
  • Wrong venue - As noted above, this is the English Wikipedia, and as such, any discussions here have absolutely zero influence over how any other Wikimedia project chooses to self-identify. The place to discuss this is at Meta (either meta:Requests for comment or meta:General requests, not sure which). --Redrose64 🌹 (talk) 17:08, 29 June 2019 (UTC)
  • Just concentrating in the English Wikipedia, which we can influence even though the WMF has made it clear that this is only influence and not power, how about just having a link in the left side panel to Other language Wikipedias? I'm not convinced that this misconception is widely held enough to justify changing the strapline. Phil Bridger (talk) 17:40, 29 June 2019 (UTC)
  • Wrong venue and even if it weren't this is like changing a chandelier in a condemned house as long as the T&S controversy rages. —A little blue Bori v^_^v Bori! 18:21, 29 June 2019 (UTC)
  • Question - "When users navigate to Wikipedia, they automatically go to the Wikipedia for the particular language that their computer is configured for" When I navigate to Wikipedia itself (rather than an article from an external search engine), in the sense that I would if I didn't get how the language prefix worked (i.e. wikipedia.org (or even .com), the page is a search page that presents some of the most popular languages around the logo, with the number of articles on each. Is there some sort of place where navigating to Wikipedia in that manner redirects you based on computer (or browser) language, or are you speaking of searching a topic in a specific language in a search engine? - Purplewowies (talk) 22:14, 6 July 2019 (UTC)
    With one exception, all links to Wikipedia pages (whether internal wikilinks or URLs from outside) are language specific; for instance, the URL for this page is https://wiki.riteme.site/wiki/Wikipedia:Village_pump_(proposals) - the language code is the en after the first two slashes. The one exception is the URL https://www.wikipedia.org/ which is the "official" front page for the entire Wikipedia; that offers various means of proceeding further, but all of them require the user to choose a language to continue in. --Redrose64 🌹 (talk) 23:24, 6 July 2019 (UTC)
    Yeah, I understand the language code thing; it just seemed like the OP was saying if you went directly to Wikipedia and your OS language was English (and if you don't already know about different languages of Wikipedia, I feel like you'd be likely to go to www.wikipedia instead of (for example) enwiki if you were going straight to Wikipedia and not Googling), then you'd be redirected to enwiki and never see the no-language-code front page, which doesn't make sense (at least to me), and that page at least gives you an inkling there are multiple projects, regardless of what you search or where you go from there. 0_o The assertion just confused me is all because it sounded like it was talking about something in a way that it wasn't a thing. - Purplewowies (talk) 04:06, 7 July 2019 (UTC)

Need your opinion on Wikipedia’s gender gap

Hi all!

Are you curious about what tools are effective in reaching Women in Red’s goals? Are you interested in contributing to the building of scalable solutions for closing Wikipedia’s gender gap?

I’m with a group of researchers working on using Artificial Intelligence (AI) tools to promote gender diversity in Wikipedia contents and thus to close the gender gap. We want to make sure you, as an important member of the community, can be heard as we build and refine these AIs.

We would like to invite you to a quick interview to share your thoughts about gender gaps on Wikipedia and the current efforts, as well as potential solutions to them. It would only take about 30 minutes over phone or video chat. We will send you a $15 Amazon gift card as a way to thank you for your time.

For more details about our project, please refer to our Wikipedia page here.

If you decide to participate, your opinion could help build the future of Wikipedia. Hope to talk to you soon! Reply to this message here or send me an email at bowen-yu@umn.edu and I can share more info and plan a time to connect. Bobo.03 (talk) 19:36, 3 July 2019 (UTC)

The best approach for Wikipedia in this area, is to adopt a gender-blind practice. Editors shouldn't be identified as male or female. GoodDay (talk) 16:28, 6 July 2019 (UTC)
That is a terrible approach. — The Hand That Feeds You:Bite 21:43, 6 July 2019 (UTC)
Not to mention it's already a thing. You don't have to bring up your gender or lack thereof unless you wish to. Heck, I'm a woman and while I mention it offhand sometimes, on the software end I'm gender-neutral in my preferences. I think gender-blind is a bad idea because it doesn't necessarily address actual issues that might be causing a gender gap in Wikipedia's editors (that have potential solutions on Wikipedia's end, anyway). (Maybe for other reasons too.) But I feel like I don't have any ideas I could put into words that are applicable to this issue on Wikipedia in terms of helping alleviate it, myself. - Purplewowies (talk) 22:08, 6 July 2019 (UTC)
  • @Bobo.03: Is there no way of participating in text (e-mail or talk page)? I'd be interested in participating but don't use telephone or video chat. Espresso Addict (talk) 07:23, 7 July 2019 (UTC)
  • What gap are you referring to? The alleged gap among editors or among articles? Or both? Are you not starting from a dubious premise, ie: that there is a noteworthy gap and that, if so, it can be fixed? All this said, I echo Espresso Addict re: the means of communication. - Sitush (talk) 07:33, 7 July 2019 (UTC) To clarify: research that has a predetermined goal of improving representation of alleged marginalised groups but which uses a method that excludes people with low bandwidth and/or hearing disabilities seems somewhat hypocritical. - Sitush (talk) 07:58, 7 July 2019 (UTC)
Hi, @Espresso Addict: @Sitush:, yes, guess we can do it through user talk page if live audio chat is impossible for you, though it’s always the best to chat alive, so that we can ask followup conversations and have a more involved chat. I’ve left a message on your talk page. Looking forward to hear back from you. Thanks!
We refer to the content gender gap (e.g., gaps among articles, etc). We are working on this project with the goal of helping close the gap and we’d hope it would work. Bobo.03 (talk) 03:36, 8 July 2019 (UTC)
@Bobo.03: As long you recognize that there's always going to be a gap, given the real world/historical bias against women. By that I mean, look at the heads of states and people in power from all of recorded history. Those are by far, men. Even today, we have roughly ~25 female heads of state, in ~200 countries (1/8th, or around 12-13%). Look at the same in science, arts, whatever. Again mostly men. Prior to the second wave of feminism, the Caroline Herschels are the exception rather than the rule. The gap should be commensurate with the biases of history.
A wording/mentality that will help you win support is language that recognizes this and wants to bring the gap to what it should be given the history of the world. Reducing the gap is good. Achieving parity (fully-closed gap) is, in many fields, impossible and undesirable. If, in the 1970s, biology had a 60% men/40% women breakdown, then biographies from the 1970s should have a rough aim of having a 60%/40% breakdown, although that has to be adjusted in light of bias against women. Many will have been prevented from having career that are as prolific as men, due to a variety of reasons, and that will skew the notability curve towards men more, so maybe the end result should be 70%/30% instead of 60%/%40. Likewise, if in the 2010s the breakdown is now 20%-80% due to a shift in who studies biology, the result should be around 20%-80% before adjusting for source/productivity bias. Headbomb {t · c · p · b} 04:00, 8 July 2019 (UTC)
Using live audio chat means you have chosen a tool that will obviously attract a very biased sample of editors. Not a wise approach when your goal is to reduce bias in another area. HiLo48 (talk) 03:46, 8 July 2019 (UTC)
Thanks for your message, Bobo.03. Editors here are very used to communicating via the medium of talk pages, and it's easy to ask any follow-on/clarification questions as necessary. Espresso Addict (talk) 03:51, 8 July 2019 (UTC)

Manual of Style for fictional characters?

Hello. Back in 2012, we discussed a possible MoS proposal on fictional characters at WP:MOS/VG and Sergecross73 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) and I made a proposal for fictional characters, using the WP:MOSANIME as a reference. A few months ago, I also proposed and withdrew an RFC here. Long story short, one of these suggestions is to propose some sort of manual of style for the fictional characters. I'm planning to open a centralized discussion to see how we can manage a MoS regarding all fictional characters (i.e. Video games, anime, novels, TV series, films, etc.). Thoughts? Lord Sjones23 (talk - contributions) 22:46, 18 June 2019 (UTC)

  • Is this meant to solve some actual problem not already covered by the MoS or some other guideline? Curly "JFC" Turkey 🍁 ¡gobble! 22:58, 18 June 2019 (UTC)
    Yes, there are a lot of disputes related to whether or not fictional characters should have their own article spun out, and there have been for many years now. It aims to give guidance with that. Sergecross73 msg me 23:08, 18 June 2019 (UTC)
    Sergecross73 how is that a MoS issue? MoS doesn't deal with content. Curly "JFC" Turkey 🍁 ¡gobble! 00:28, 19 June 2019 (UTC)
    Look, I don't care where its hosted, or even if my guidance in particular is used. I want there to be a wide-ranging discussion where we can get an enforceable consensus, because the recurring disputes in the area are both a massive time sink and a source of sour feelings among many disagreeing-but-very-good-editors. Sergecross73 msg me 01:00, 19 June 2019 (UTC)
    What are the recurring disputes? Why would having a character MOS be more effective at preventing them than letting the MOS for the various media set their own guidelines? Argento Surfer (talk) 13:10, 19 June 2019 (UTC)
    My two comments above just explained the problem and what I wish to accomplish. I don’t understand why this is so hard to understand. I’ve observed years of disputes and I wish to cut down on them. This is all very bizarre. I’ve never encountered so much skepticism for a desire to solve a problem while having complete openness on changing their stance. I’d get it if I had a controversial stance. But I just want resolution of any kind. Sergecross73 msg me 23:13, 19 June 2019 (UTC)
    I re-read your comments twice, and maybe I'm blind, but I do only see you talking about "recurring disputes" without links or descriptions. Do these disputes have recurring themes? Do they often end with outcomes that conflict with similar, earlier discussions? Without details like that, it's I find it impossible to evaluate the potential impact of your proposal. Argento Surfer (talk) 13:05, 20 June 2019 (UTC)
    • At least to me, yes. Our articles on notable fictional characters particularly in any form of serial work often focuses far too much on primary material. For example Rick Grimes (which actually has a decent "out of universe" set of sections but still has far too long in the tooth on the fictional biography), and I'm sure I can find more with some time. People writing these fictional biographies tend to want to go by breaking it up by each serial element (episode, comic issue, etc.) rather than describe the broad trends. No existing MOS or P&G really says anything against this, barring the lack of secondary sources for notability. Because we tend to allow works of fiction to serve as sourcing for themselves, these articles seem to get away with excessive reliance on primary sourcing.
    • I would then probably add that the focus of these articles should be on the out-of-universe facets more than the in-universe ones. How was the character conceived? How has the character changed over the years? How have they been received in the world of critics? etc.
    • Then another whole thorny issue is when you have multiple iterations/versions of the same character, ala something like Robin (character) especially when it comes to NFC use. That's a whole pickle that we really haven't touched on. --Masem (t) 00:17, 19 June 2019 (UTC)
      • "How have they been received in the world of critics?" Why? This is at best a trivial aspect of the topic and of minimal interest to a reader. I have a few relatives (my sibling, a few cousins, and a niece) who are Wikipedia readers, but not editors. They only read the plot sections and just ignore whatever "critical" opinion is added as indifferent. Dimadick (talk) 16:19, 22 June 2019 (UTC)
        • So, because people misunderstand the purpose of Wikipedia, and misuse it accordingly, we need to accommodate that? Wikipedia isn't supposed to be Cliffs Notes For Pop Fiction. -Jason A. Quest (talk) 16:28, 22 June 2019 (UTC)
  • To clarify, is the text of User:Sjones23/Proposal what is being proposed here? Satellizer el Bridget (Talk) 00:47, 19 June 2019 (UTC)
  • Support at least some set of guidelines. I would estimate that we have tens of thousands of articles on fictional characters, mostly comic book characters. bd2412 T 00:54, 19 June 2019 (UTC)
  • Support I think this is a great idea.Blue Pumpkin Pie (talk) 01:01, 19 June 2019 (UTC)
  • Oppose as instruction creep, until it can be demonstrated this will solve concrete problems our guidelines don't already address, rather than be a collection of pet prescriptions. Curly "JFC" Turkey 🍁 ¡gobble! 01:55, 19 June 2019 (UTC)
  • I think Masem does bring up some good points. I give the example of Sansa Stark, a major character that appears in two different mediums, and with two very different storylines. Right now the article is 75% in-universe retelling of her story by book and by season (all unsourced, naturally) and only then comes the real life coverage of the character. This is excessive reliance on primary sourcing even on a well-known character with a number of reliable sources available. I think WP:PLOT argues that summary descriptions of works should be limited, yet it's not being done in many (most?) character articles. Then there's the whole issue of having hundreds of articles like Griffin Castillo, AJ Chandler, Nick O'Bannon, Nitro (comics), A. J. Chegwidden and Natalie Marlowe that obviously fail MOS:REALWORLD on a whole (as in, there's no independent sourcing on these characters). I think that the rules do exist regarding coverage of fictional elements in wikipedia voice but I'd personally welcome some discussion regarding what we should reasonably expect from an article about a fictional character (development, reception, difference between original work and adaptations, merchandise, casting, etc.). RetiredDuke (talk) 18:23, 19 June 2019 (UTC)
  • I also think this could be expanded to articles that handle more than one character and List articles that handle characters.Blue Pumpkin Pie (talk) 21:42, 19 June 2019 (UTC)
    I would definitely think that we can include "list of characters" as part of a MOS for fictional characters in general. We're not talking notability here (there is no specialized notability for fictional characters, they are expected to meet the GNG), but the biggest issue in both single character and character lists is that the content from primary seem to be around 90% of the article, ideally it should be 50% or lower. Outside of WP:NOT#PLOT, and the little that is in WP:WAF, there is nothing to help with this imbalanced primary/secondary ratio. --Masem (t) 23:20, 19 June 2019 (UTC)
  • Don't support the current wording of User:Sjones23/Proposal, if this is what is proposed, but do support a centralized MoS guideline, as currently TV has Wikipedia:Manual of Style/Television#Character article structure, WikiProject Fictional characters has Wikipedia:WikiProject Fictional characters/Style guide, Video games have Wikipedia:Manual of Style/Video games#For characters, comics have Wikipedia:Manual of Style/Comics#Characters 2 and there are probably others. This needless fork of guideline has in certain situation also conflicting style guides. --Gonnym (talk) 00:07, 20 June 2019 (UTC)
    I plan to merge all of the guidelines there into a single MoS guideline. Lord Sjones23 (talk - contributions) 05:57, 21 June 2019 (UTC)
  • Oppose per WP:CREEP. I just had a look through the FAs of this sort. To start at the top, consider the vexed question of infoboxes. Should fictional characters have an infobox like Jabba the Hutt or not, like Tom Swift? There's no practical consensus on this, is there? Andrew D. (talk) 09:04, 20 June 2019 (UTC)
  • Oppose as instruction creep, the question of standalone notability for a fictional character should be determined by WP:GNG on a case by case basis, while the MOS is not the right area for such decisions, thanks Atlantic306 (talk) 11:54, 20 June 2019 (UTC)
  • Oppose per User:Atlantic306 and User:Andrew Davidson's rationale. Would've supported per WP:NOTCREEP however the matter seems a lot more complicated and integrated into wikipedia. Consensus would seem very mixed on the matter too so, echoing Atlantic306 I'm going to emphasize his/her argument that "Standalone notability ... should be determined by WP:GNG on a case by case basis."
  • Oppose I made an essay in 2016, which is linked as WP:A&M/CHARACTER based on common layouts found on GA and FA anime and manga related character articles. This being said, we already have so many projects doing their own thing here. In theory its a good idea, but implementing it across Wikipedia is another matter. - Knowledgekid87 (talk) 15:57, 20 June 2019 (UTC)
  • As seen by what Gonnym pointed to, we already have style guides for fictional characters. And we have Wikipedia:Manual of Style/Writing about fiction. Flyer22 Reborn (talk) 05:12, 21 June 2019 (UTC)
    • That doesn't solve a lot of problems with fictional characters. In recent months I've seen various problems for which there have been no specific answers, even for simple things like how you should write the chaacter's name in the lead sentence. A common thing that I see is editors not being able to separate fiction and reality. They like to add birth dates, often based on OR, or claim citizenship for particular characters based on how it applies to the real world. When you try to refer to WP:WAF or other guidelines to resolve the problem, there is no guidance in the area. We really do need something specifically for fictional characters. --AussieLegend (✉) 06:22, 21 June 2019 (UTC)
      • So which MOS or essay do you propose we go by? We have an MOS mention for comic book characters, an MOS mention and essay for anime characters, a style guide for fictional characters, an MOS mention for television characters, and an MOS about writing about fiction. - Knowledgekid87 (talk) 15:23, 21 June 2019 (UTC)
  • SMcCandlish and I have previously discussed a centralized MOSWORKS (see also Talk:Virtual Pool 3). It would be a massive undertaking. I'd be willing to work with other editors to consolidate our guidance on works, fictional and otherwise, of which the characterization is a part. That said, I would reject the 2012 Sjones page out of hand. --Izno (talk) 16:26, 22 June 2019 (UTC)
    • Since a few of us in this thread repeat this sentiment, maybe the question for a RfC shouldn't be if we should adopt Sjones's page, but wether we should consolidate the various MoS and essay pages on fictional characters into one MoS. --Gonnym (talk) 09:31, 27 June 2019 (UTC)
  • Oppose per User:Atlantic306 and User:Andrew Davidson.--Vulphere 06:19, 27 June 2019 (UTC)
  • Oppose. We're not currently at a state where we could "solve" all these diverse series of issues all at once. Yes, various fictional characters are treated differently in WP, because the fiction treats them differently. Maybe would devise some sort of classification system and create useful guidelines for each, but that's just step one of many required, and that by itself is too big a step. Perhaps we could start with a few essays that suggest some ideas for how some types of fictional characters could be identified and treated, and see if that clarifies how we might start to find a way to cover everything. All I know is dictating something right now would actually delay these preliminary steps, and inhibit a workable solution. --A D Monroe III(talk) 21:05, 27 June 2019 (UTC)
  • Comment to several of the opinions above:
    • We are not talking about fictional character notability. We've tried setting a standard, and there just isn't any. Fictional characters must show they meet the GNG with secondary sourcing about the character, to have a standalone article. This proposal does not change that.
    • I agree that in detail, how a comic book character is treated compared to a film or television character will be significantly different at that level, but at the broad scope, there are still many common things we expect to see in all articles on fictional characters: concept/creation, development, a brief fictional summary, and reception to the character. Regardless of the media, every character should have something akin to that. There are MOS elements that apply across the board, how to write about in-universe events, concise plot aspects, etc. We don't want to get too far in the way of special approaches needed in, say, comic books for generational characters or those with many different iterations, but the same basic concepts that would apply to a notable one-off character apply there. Should a MOS for fictional characters be developed it is not intended to step on the toes of any other medium's specific MOS, and should be harmonizing those parts. --Masem (t) 18:34, 8 July 2019 (UTC)

Hidden category: Pages which will not work if moved

I suggest we create a hidden category, something like Category:Pages which will not work if moved, mostly to be populated by those templates which, well, will not work if the page is moved, as they use {{PAGENAME}} in a non-trivial manner. The only ones I'm sure of are the year articles, using (directly or indirectly) {{Year in various calendars}}, but I'm sure other projects than WikiProject Years have templates which will cause trouble.

I suppose {{DISPLAYNAME}} (although not exactly a template) may also require work, but that should be a bit obvious if the mover actually looks at the page before moving it. — Arthur Rubin (talk) 18:59, 8 July 2019 (UTC)

It's always good to identify a problem before proffering a solution. Apart from the pages using {{Year in various calendars}} (which we know for sure they're not going to be renamed overnight without discussion) what other set of articles fall into this description? – Ammarpad (talk) 09:05, 9 July 2019 (UTC)
I don't know of any other systematic problems, but I've been active in WikiProject Years for some time. I suppose a database search for templates using {{PAGENAME}} might be productive, although I noticed that there are some templates which used to use {{PAGENAME}} which now use LUA modules. There are definitely some categories which use {{PAGENAME}} to locate their primary article as displayed, so that if either the article or the category is moved, the category text will be wrong. — Arthur Rubin (talk) 08:40, 10 July 2019 (UTC)
If we take the example you gave of {{Year in various calendars}}. Without diving into the code that much, I don't see how any change in titles should break its usage if it was coded correctly. You have about 4 styles available: 3 BC, AD 1, 2000 and 911 (year). If the code is set up to only look for numbers and unless the words "BC" and "AD" are changed, I don't see how anything should break with a page move from "911 (year)" to "911" or from "AD 1" to "1 (year)" (or even from "911 (year)" to "911 (best year ever)"). Before tagging pages with "will break if moved" its a better idea to first see if the design is set up correctly. --Gonnym (talk) 09:01, 10 July 2019 (UTC)

Minceraft easter egg

Minceraft is Minecraft easter egg. Please create easter egg section in Minecraft article and redirect Minceraft there.

My account
My talk
My edits

09:14, 10 July 2019 (UTC)

Discuss at Talk:Minecraft. Doesn't fit here. (And please see WP:SIGNATURE.) — Arthur Rubin (talk) 10:05, 10 July 2019 (UTC)

RfC: Deprecate webcitation.org aka WebCite

This RfC is to allow editors and archive bots the voluntarily leeway to stop using webcitation.org and replace existing webcitation.org URLs with other archive providers where available. To begin divesting from WebCite. 14:49, 13 June 2019 (UTC)

Background:

  • Approximately 5% of Enwiki archive URLs are to webcitation.org, 5% to archive.today, 2% to "others" (Library of Congress, etc), and 88% to archive.org - in raw numbers there are about 5 million archive links of which about 250,000 to are to webcitation.org
  • webcitation.org is unreliable. Talk:WebCite#Service_outages lists known outages and there have been others. Outages can last for days and weeks.
  • WebCite is a non-profit and almost shut down in 2013 due to lack of funding. The site has not changed since - documents, features, bugs etc.. no evident development of the service or changes to the website in years. Bug reports go unanswered and unresolved. It appears to be the work of Gunther Eysenbach and not a full-time occupation.
  • WebCite is one of the oldest archiving services. It was unique for archiving on-demand vs. automated crawling. On-demand archiving is now available at Wayback, Archive.today etc.. a standard feature at most archive services. There is nothing that sets WebCite apart that other archives can not do, and do better.
  • WebCite uses a system of accepting archive requests, returning an archive URL, backgrounding the job then emailing if the archive was successful or not. Often users submit a job and get the URL and paste it into Wikipedia without waiting to see if the archive request was successful. As a result:
  • WebCite has the highest rate of archive link rot. My bot WaybackMedic monitors archive links and WebCite is the leader in terms of raw numbers of links that need replacing with other archives, despite only representing 5% of the total archives.

Proposal:

  • Archive diversity is important. WP:WEBARCHIVES lists about 20 archive providers currently in-use on Enwiki. Plus, not every archive has every page, some will have a page that others do not (eg. archive.org does not have everything). In the end it is up to users which archive provider they choose.
  • This RfC would demonstrate a general best practice of avoiding and/or changing WebCite URLs to other archive providers. Deprecate does not ban the site or make a hard red-line rule. It would give users and bots some leeway to begin changing URLs and point to this RfC as a rationale. It would change the documentation to encourage users to use a different provider. Users who still wish to maintain a WebCite URL can add {{cbignore}} to keep bots away and act as a notice to maintain the URL. If WebCite is the only source for an archive it should obviously be kept and not converted into a {{dead link}}. -- GreenC 14:49, 13 June 2019 (UTC)

New Developments (July 10, 2019):

  • Webcite is now back online. What happened this time is unknown.
  • They are not accepting new pages to be saved.
  • As the RfC nominator I should disclose that I am now a Paid Editor of Internet Archive, which happened recently after the RfC. More information at User:GreenC/Paid editor. I am not paid expressly for this project or RfC but I guess anything is related. This RfC was initiated on my own volition, was not requested by anyone nor is it connected to why I became a paid editor. A 5 week outage with no communication from WebCite, and the long history of outages, is why.
  • Bots started replacing dead WebCite links abut that has stopped since they are online. -- GreenC 17:13, 10 July 2019 (UTC)

Survey (deprecate WebCite)

  • Support per above and survey bump. -- GreenC 14:49, 13 June 2019 (UTC)
  • Support I used to use WebCite but Wayback does everything it did, and better.-- Pawnkingthree (talk) 16:34, 13 June 2019 (UTC)
  • Support per the above. Kudos to the initiator for one of the best written proposals I've seen on Wikipedia. Thryduulf (talk) 21:43, 15 June 2019 (UTC)
  • Support. It's clearly beneficial both to readers and editors to prefer archive sites which are more stable and actively maintained, if they are equivalently archiving the content. Alsee (talk) 06:06, 16 June 2019 (UTC)
  • Support It is out of service again and is unreliable due to its outages. The archive for links that are dead needs to be reliable. AhmadTalk 16:29, 16 June 2019 (UTC)
  • Support its better to use a archive website which is more reliably up, so that our readers can nearly all of the time see the archived source. I agree that outright banning of WebCite is a bad idea, as diversity in archive websites is a good thing, but conversion to Wayback is something which (unless WebCite becomes more reliable) needs to be done. Dreamy Jazz 🎷 talk to me | my contributions 21:16, 18 June 2019 (UTC)
  • Support - per above. ___CAPTAIN MEDUSAtalk 17:58, 19 June 2019 (UTC)
  • Oppose for the reasons I wrote below. All of the arguments given here are why other archivers are better than WebCite. They aren't reasons why WebCite is useless or detrimental except insofar as there is a better alternative. My position is that the best solution would be making it so that we can use multiple archivers. Redundancy. A citation has a WebCite archive? Add one for archive.org and archive.to. There are problems with all of them. That's not to say that the others aren't overall better, but that it doesn't need to be a choice. If we can use multiple, nothing is gained by removing WebCite. — Rhododendrites talk \\ 05:16, 20 June 2019 (UTC)
  • Support; at the very least, using WebCite to save pages that are currently live should be discouraged since better options are clearly available. Jc86035 (talk) 10:48, 20 June 2019 (UTC)
  • Support - Seems like a reasonable proposal. Editors can continue to use "WebCite" if they wish, it just wont be via bot. - Knowledgekid87 (talk) 16:25, 20 June 2019 (UTC)
  • Support - There are no indications that the situation with WebCite will improve in the future; instead, it is reasonable to expect further deterioration. — kashmīrī TALK 09:54, 22 June 2019 (UTC)
  • Support - I think that WebCite has to be given full credit (with citations :)) for (apparently) being a pioneer in on-demand URL archiving. I'm not sure how to do that, apart from solidifying its Enwiki entry. But unless the WebCite maintainer(s) very quickly inform Wikipedia (or the world) about a major overhaul and long-term sustainability project and convince us that the probability of future down time will drop to very low, this proposal makes sense. The world of knowledge should not be dependent on a single well-intentioned, hardworking individual. See the discussion section below for a related proposal of implementation, which seems to implement Rhododendrites' point above: add archive1url, archive1date, dead-archive1url, archive2url, archive2date, dead-archive2url, ... parameters to the standard citation template; possibly retain the WebCite urls but convert them to archive2url, archive2date, dead-archive2url=yes. [Comment: I have added a huge number of WebCite urls to Enwiki and I'm hoping that webcitation will return to online status at least long enough to make sure that alternative archival backups can be created. A lot of articles risk being greatly weakened without archival references, and this especially affects WP:BIAS.] Boud (talk) 16:43, 22 June 2019 (UTC)
  • Support per above.--Vulphere 05:50, 27 June 2019 (UTC)
  • Support per above. Johnbod (talk) 00:38, 2 July 2019 (UTC)
  • Support no downside, lots of positives. Headbomb {t · c · p · b} 01:05, 3 July 2019 (UTC)
  • Support with certain qualifications. In software development, 'deprecated' usually means the use of the feature is discouraged and it will most likely be removed in a future version. I think it should just be discouraged indefinitely, or until the service becomes trustworthy again (or completely dysfunctional). And I think it should be acceptable to use WebCite as a secondary archive, as a backup. Archive services go down or become untrustworthy. If Wikipedia is supposed to exist indefinitely then using just one archive service for a source is probably not a good idea. Template:Web cite only supports one archive link at the moment, but Template:Webarchive supports several (Thanks to User:GreenC for pointing that out). Cite-web should probably be expanded to allow multiple archive links. Bots should only add archives, not remove or replace archive links unless they are dead. Hecato (talk) 15:44, 10 July 2019 (UTC)

Discussion (deprecate WebCite)

@Rhododendrites: (moved from the survey to discussion section). Yes the RFC proposal says exactly this, you can use WebCite, if you want. But there are good reasons to deprecate. Deprecate does not mean "you must not use" or blacklist, it means archive of last resort and default switch to others when possible. It isn't about picking favorites, I really do wish WebCite were available and reliable. -- GreenC 01:37, 17 June 2019 (UTC)
Aside: not sure why, but this didn't generate a notification for some reason? Yes the RFC proposal says exactly this ?? I said we should allow use of as many archives as possible. This is a proposal to not use a particular archive. Regardless of whether it's a suggestion or a hard rule, all of the reasons are predicated on the idea that we shouldn't use it because others are better. I say we shouldn't have to choose one over another. The best solution is finding a way to take advantage of all of them. WebCite may not be as good as another service, but WebCite and that other service is better than either one. If you see a WebCite citation, supplement it with an archive.to and/or archive.org; none of these are reasons to replace. — Rhododendrites talk \\ 05:10, 20 June 2019 (UTC)
@Rhododendrites: WebCite is offline. http://webcitation.org is dead. Maybe they will come back? These extended outages are not new, though I've never seen it go this long. The outages are getting longer, more frequent, the site is not maintained or updated.. no updates or news on Twitter or anywhere about what is happening. Emails to the owner go unanswered (as always). So I'm confused why you said "all of the reasons are predicated on the idea that we shouldn't use it because others are better". Unless by better you mean "not dead". -- GreenC 16:07, 20 June 2019 (UTC)
@Rhododendrites: It seems to me you're making a proposal for a modification of Wikipedia:Citation templates: allow the use of multiple archival parameters, e.g. archive1url, archive1date, archive2url, archive2date, ... The more critical a Wikipedian thinks that the reference is, the stronger his/her motivation to list at least two archived copies of the reference. A maximum number of archives should probably be set - 2 or 3? By default, the second and subsequent archivenurls would be hidden or semi-hidden from the reader; if the archive is long-term dead, then a bot could easily swap between them. A simpler possibility could be to add a dead-archive1url, dead-archive2url, ... parameter, similar to the present dead-url=yes|no. This proposal might let robots add new archive1urls while converting existing Webcite archiveurls to archive2urls with dead-archive2url=yes, rather than deleting the webcite urls. This would be useful for cases where Webcite has a good quality copy (in terms of avoiding javascript rubbish, zillions of external scripts, and so on) but the other archiver doesn't. Boud (talk) 16:28, 22 June 2019 (UTC)
This already exists with {{webarchive}} which supports up to 10 archive URLs and was made for this purpose.
{{cite web |url=http://example.com |title=Example website |archiveurl=http://web.archive.org/web/20190101000000/http://example.com |archivedate=2019-01-01}} {{webarchive |format=addlarchives |url=http://archive.today/20190609163259/http://example.com/ |date=2019-06-09 |url2=https://wayback.archive-it.org/all/20190621232545/http://example.com/ |date2=2019-06-21}}
Produces:
"Example website". Archived from the original on 2019-01-01. Additional archives: 2019-06-09, 2019-06-21.
To be honest though few people use it, and not many people add archives at all much less worry about redundancy. I wouldn't worry too much about it, bots can replace dead archive URLs with other archive URLs. My bot could fix the WebCite problem in a couple weeks if needed and so can IABot. We have bots for this. The only question is how many of these URLs are unique to WebCite that no other archive provider has, thus are irreplaceable. This is an open question that will be answered once the bots start replacing URLs. -- GreenC 16:57, 22 June 2019 (UTC)
Thanks for sharing this. First time I've seen {{webarchive}}. I think it would be better built into the citation templates, but that the functionality exists is good to know. I do still feel like we (or maybe just I) don't have the sufficient information to write off WebCite for good. Unless we know it's gone forever, if it's the lone archive of a page, a temporary broken link seems preferable to none. If it's not the lone archive, it would be just as easy to supplement it with another archive as it would be to replace it. — Rhododendrites talk \\ 18:05, 23 June 2019 (UTC)
It's nice to know this already exists. I don't expect that I'll be paranoid enough to use it often - it's enough work to add a single archive for each reference. But we'll see: I wasn't paranoid enough to expect webcite to have such a long down time... Boud (talk) 00:56, 24 June 2019 (UTC)

Support with amendment "Archive diversity is important..." agreed. We should avoid discouraging people from using WebCite, while archiving content with other services. Other services could go down as well. The most important reason to continue archiving pages with WebCite is addressed in the article on this service: "WebCite checks robots.txt only at the time of archiving, Internet Archive checks robots.txt occasionally, so changes in robots.txt (which can be caused by a change in the ownership of the domain name) can result in removing the cached pages from the Internet Archive." Otherwise the new owner of a URL could destroy all record of the publisher who owned the URL before by using robots.txt.--Truthtests (talk) 22:19, 9 July 2019 (UTC)

That robots.txt information is outdated. Internet Archive largely ignores robots.txt in part for the reason you describe. More information at Wayback Machine. -- GreenC 22:48, 9 July 2019 (UTC)

RfC: WP:Dashboard on sidebar

As it (to me at least) appears to be the easiest way to access ongoing discussions, I think it should be on the sidebar (maybe below the Com. Portal). Should it? Remagoxer (talk) 10:04, 11 July 2019 (UTC)

Yep, go for it. ——SerialNumber54129 10:12, 11 July 2019 (UTC)
I cannot, as I am not an iadmin and cannot find it on the Wikidata page (I guess I should clarify this was brought here because it would be a site-wide change). Unless I'm just confused? Remagoxer (talk) 10:29, 11 July 2019 (UTC)

Semi-protect templates by default

Did you know why most of the templates are protected? It's because they're high risk. To prevent vandalism, we should do this. Is that okay? 114.124.165.28 (talk) 09:16, 12 July 2019 (UTC)

This is already done where appropriate; see User:MusikBot II/TemplateProtector. Protecting each and every template by default is probably overkill. -- zzuuzz (talk) 09:44, 12 July 2019 (UTC)
Also, any vandal who knows enough to go mess with the templates would probably already be Autoconfirmed. Nosebagbear (talk)

Proposal/RFC: Recoloring page-protection padlock icons to be consistent with the interface

There is a clear consensus to replace the current design with the proposed design for:

  1. Semi-protection
  2. Move protection
  3. Pending changes protection
  4. Extended confirmed protection

Permanent protection was not changed.

Some editors objected to replacing the current design with the proposed design for:

  1. Full protection
  2. Template protection

largely because of the concerns raised by pythoncoder:

The full protection and template protection locks look too much like the interface-protected lock vs. under this proposal. We should not be making the locks look identical in the name of branding.

There is no consensus for or against the "full protection" and "template protection" proposed icons owing to many editors not specifically discussing them so there is no prejudice against opening a new RfC to discuss only these two proposed icons.

Cunard (talk) 09:37, 14 July 2019 (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.

Hello everyone. Padlock icons have been redesigined to be more accessible which is great but they lack one small part, using the consistent color scheme we are using in the interface. Recently, several parts of the interface have been recolored to algin with the software interface. More generally speaking Wikimedia UI style guide. You can see the discussions in Special:Diff/754712927. In short, we use the same blue shade (#3366cc) as much as possible, from "Publish edit" button to the left border of ambox (notice) to color of links in mobile frontend, this blue-ish plus a dedicated set of grays is to give feeling of ink and book and giving a consistent look/experience to readers and sort of brand ourselves with those colors. Lots of small and invisible changes have been made (like chaning background of wikitable and infoboxes) to help aliging with the consistent color scheme. This padlock icon recoloring is a good step too IMO. Most changes are invisible to naked eye and we don't need to agree on all of them, you can shout out that color of padlock "foo" seems wrong to you. You can see the reasoning behind this color scheme in Wikimedia UI style guide.

Type of protection Current design Proposed design
Permanent protection †
Permanently protected
Permanently protected
Permanently protected
Permanently protected
Full protection
Fully protected
Fully protected
Fully protected
Fully protected
Template protection
Template-protected
Template-protected
Template-protected
Template-protected
Semi-protection
Semi-protected
Semi-protected
Semi-protected
Semi-protected
Move protection
Move protected
Move protected
Move protected
Move protected
Pending changes protection
Pending changes protected
Pending changes protected
Pending changes protected
Pending changes protected
Extended confirmed protection
Extended confirmed protection
Extended confirmed protection
Extended confirmed protection
Extended confirmed protection

† No change, added for reference

Do you support this change? Thanks! Ladsgroupoverleg 21:09, 29 May 2019 (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.

Article Interlink Pages

If a topic does not meet general or subject-specific notability guides, but is noteworthy enough to be covered in some degree at another article, then it can be redirected (with or without merge) instead of being deleted. If a topic of marginal notability is covered at two or more articles and there is no clear primary redirect then this doesn't work. An "Article Interlink Page" (Ok, there is probably a better name) would allow a better and consistent handling of topics of some level of noteworthiness but limited RS coverage. It would be not entirely unlike a disambiguation page or a Set Index Article, and would consist of:

  • 1-2 fully-referenced sentences outlining the topic and ending in a colon
  • A bulleted list of brief claims of noteworthiness, each with a bluelink where the topic is covered and an RS reference. Links to indefinitely bounded lists are not to be included (eg, a list of those holding a particular notable position is fine, while a list of people in a particular occupation is not)
  • An AIP footer (different for different types of AIP) which would run something vaguely like This Article Interlink Page is for a person who appears in multiple articles. It should be converted to a full article only if they can be shown to have significant coverage in multiple independent reliable sources that meets Wikipedia's notability guidelines such as for general biographies or for creators.
  • Reflist
  • Appropriate categories

I believe that this restricted format would:

  • provide an intermediate level of inclusion between those who should have no article and those who should have a full article -- something approximating a mini Who's Who entry.
  • allow a less bitey way of handling (particularly) a bunch of biographical articles of marginal notability without opening the floodgates for definite non-notables
  • be resistant to promotionalism
  • simplify some decisions at WP:AFC and WP:NPP
  • reduce some of the inflows into AFD and provide an alternative to deletion for some of those which do make it there.
  • be better than a bunch of scattered redlinks (possibly with inconsistent naming)
  • be searchable/categorisable (and probably highlightable in article text with script)
  • be potentially bot-identifiable where restrictions are not met (>2 sentences in intro, bullet without reference, bullet without bluelink, bluelink without mention, link to indefinite list, ...). Removal of the AIP template should triggers NPP as conversion of a redirect does.
  • provide some guiderails for editors who wish to expand the topic

Ultimately, having the AIP might also allow us to escape the currently useful trap of presumed notability for new articles of sportspeople (as well as others such as bishops) who have limited independent and significant biographical coverage immediately available, but who would generally appear at multiple articles. They could instead be given an AIP with links to their coverage at seasonal articles (diocesanal articles, etc) until sources are actually found. ~Hydronium~Hydroxide~(Talk)~ 10:46, 7 July 2019 (UTC)

Often a topic can be shoehorned into a location article. Eg a school, or a shopping centre could be covered in that geographic location. I am not very convinced by the set index for a non-notable topic. It would be better to redirect and then link from the section to other relevant sections. Can you think where this is needed? One example could be the location of some crime that is newsworthy enough to make a location article, and the business could be part of a chain. But it is probably "undue detail". Graeme Bartlett (talk) 12:11, 7 July 2019 (UTC)
@Graeme Bartlett: Some examples of the type of thing where I see an AIP as a useful option would be:
  • Musical groups with multiple bluelinked members (potentially meeting NBAND#6) but not sigcov
  • Musicians with extemely limited RS biographical coverage who appeared in multiple bluelinked bands (potentially meeting NBAND#6)
  • Creators with limited public profile who don't meet WP:CREATIVE but with multiple works that would meet NBOOK, NFILM, etc due to a marginal level of critical coverage.
  • Minor actors with multiple film/tv feature roles and basically no RS bio coverage
  • Winners of bluelinked pageants with limited coverage who subsequently went on to a further bluelinked pageant
  • Companies with limited coverage but multiple notable products
  • Unsuccessful party political candidates with some level of coverage at multiple bluelinked elections
~Hydronium~Hydroxide~(Talk)~ 13:27, 7 July 2019 (UTC)
I think it could be case where WP:XY applies. Emir of Wikipedia (talk) 21:26, 7 July 2019 (UTC)
  • Oppose this idea. I believe there is value in in-prose redlinks because they encourage eventual article creation (even if that means waiting until the subject's notability can be demonstrated). I also think creating an additional set of pages that are exempt from WP:N is a bad idea. UnitedStatesian (talk) 21:32, 10 July 2019 (UTC)
  • I don't think this is a bad idea. In a way, that's almost what already happens if the subject's name is ambiguous: there'll be a dab page and the relevant entry there is sort of a mini version of what an interlink page would look like. – Uanfala (talk) 17:08, 14 July 2019 (UTC)

Password policy for users with certain advanced permissions

I think the current password policy isn't that effective for some reason. There are still compromised accounts that are trying to edit the Main Page. I think we need a new password policy for these users.

The new policy is:

  • at least ten characters including at least a capital AND a lowercase letter
  • at least a number and a symbol
  • shouldn't be in the fifty most common passwords

Thanks 114.124.165.28 (talk) 09:34, 12 July 2019 (UTC)

See m:Password policy. The most common attack vector is actually passwords shared with and leaked from other sites. It doesn't matter how complicated a password is if it's being read elsewhere. Users with advanced permissions also have access to 2FA. -- zzuuzz (talk) 09:41, 12 July 2019 (UTC)
Enforcing what appears in a password is known to negatively impact recall of the password, and That Leads To Re-use. However, two of your requirements are already met; see link above. --Izno (talk) 14:01, 12 July 2019 (UTC)
I think the meta password policy is sufficient for advanced users without specifying which character components are necessary. — xaosflux Talk 13:24, 14 July 2019 (UTC)

I'd personally like to see an optional 2nd factor introduced into the login process ... or is that, in fact, already available? --User:Ceyockey (talk to me) 02:32, 15 July 2019 (UTC)

​It is available. See Help:2FA. — JJMC89 (T·C) 03:52, 15 July 2019 (UTC)

Option to disable Wikimedia project greetings

Whenever I visit a Wikimedia Foundation website for the first time, it always leaves a welcome message on my talk page.
Granted, the talk pages for different projects are kept separate, but these messages seem presumptuous at best.
It would be nice if there was an option to opt out of greetings, so that I could go from project to project without needing to bother with dismissing notifications. Daniby2013 (talk) 05:26, 16 July 2019 (UTC)

There are no such automated greetings here, and we can't control here what people on other projects do. You may want to take this to somewhere on Meta. Anomie⚔ 11:18, 16 July 2019 (UTC)
@Daniby2013: OK, so it looks like you have 22 attached accounts for WMF public wiki's. Of those, it looks like you were greeted by a person twice, a bot 3 times - but most of the time (17 times) noone greeted you at all. Are you seeing something different, because it seems very far from "always". If you don't like how a specific project greets people, you would have to bring it up with them. — xaosflux Talk 01:54, 17 July 2019 (UTC)
@Xaosflux: I seem to have misremembered the frequency with which these messages are sent, but I reaffirm that a message being sent without any prompting is still bothersome.
However, seeing as this is a niche issue with a solution requiring significant changes to the Wikimedia infrastructure, I suppose I'll just have to make do. Daniby2013 (talk) 09:06, 17 July 2019 (UTC)
@Daniby2013: OK, if you "edit" on lots projects you may get a bunch of the "congratulations on your first edit" notifications. You may be interested in following phab:T21161 and the related task phab:T30369 that could alleviate your original condition if they were implemented. — xaosflux Talk 12:10, 17 July 2019 (UTC)

Merge F9 with G12

See WT:CSD. 114.124.234.199 (talk) 03:56, 18 July 2019 (UTC)


Request for comment: Set a time limit for blocks on the 2607:fb90::/32

See WP:ANB. This guy got blocked 1 year, TonyBallioni says it's "conservative" because this IP has a long-term pattern of disruption since 2016. 125.161.139.188 (talk) 13:11, 19 July 2019 (UTC)

Proposal for a policy to speedily move advert/COI pages to draft

We have over 18,000 pages tagged as {{advert}}, and nearly 13,000 tagged as {{COI}}. Some of these are actually in reasonably good shape, but need to be slightly more balanced and have some puffery removed, while others are barely more than a resume or a page of promotional jargon. In the middle ground, there are a substantial number of pages that are for individuals and entities that are probably notable, and which are not fit for speedy deletion under CSD:G11 as unambiguous advertising or promotion, but which also are not in a shape to properly serve our readers. As an administrator, I probably deal with more of those than the average editor. I would like to be able to speedily move pages that are farther towards the bad end to draft space. I propose the adoption of a policy structure along the lines of CSD:G11, but directed at articles that are theoretically fixable, but predominated by advertising, promotion, or clear COI content to the point that they require substantial revision to be a useful and credible part of the encyclopedia. bd2412 T 00:50, 27 June 2019 (UTC)

I agree with this concept. In borderline cases where there is some genuine encyclopedic content, it is better to preserve it as a draft than to delete it outright. Any good faith editor can do cleanup work and then move the draft back to main space. Cullen328 Let's discuss it 04:16, 27 June 2019 (UTC)
I would support this in principle. My main concern is in borderline-borderline cases where there are roughly equal amounts of promotion and content, but I think such concerns could be ameliorated and are not fatal to the idea. – John M Wolfson (talk • contribs) 05:27, 27 June 2019 (UTC)
Just to pick an example to see how this would work. NASCAR is marked advert. Would you like to draftify it? ☆ Bri (talk) 03:19, 28 June 2019 (UTC)
  • That is a good question, and the answer is no, since that page is not clearly "predominated by advertising, promotion, or clear COI content". This would be a policy directed at pages that have some smattering of salvageable content, or are clearly notable topics that should have an article, but which have very little on the page that is not advertising, promotion, or clear COI content. Basically, it would cover pages that fall outside CSD:G11, but whose content does not really serve readers looking to learn neutral and unbiased information about the subject. 04:25, 28 June 2019 (UTC)
What would the eventual fate of such a page be? I am talking empirically, not in terms of policy. Jo-Jo Eumerus (talk, contributions) 07:55, 28 June 2019 (UTC)
  • Empirically, the fate of such a page will be whatever editors make of it. I have previously solicited the creation of a banner for pages that are sent to draft through AfD ({{AfD-userfied}}), and I these pages would be similarly tagged, so they would show up in a maintenance group together. Of course, the ones that no one really thinks are worth having in the encyclopedia will end up being abandoned, which is a better result then having them abandoned in mainspace. bd2412 T 16:04, 28 June 2019 (UTC)
Support as a part of new page patrol. Quarantining new promotional articles in draft space deprives spammers of what they want - being indexed by Google. I quarantine a lot of suspected undisclosed paid adverts - from what I've seen about 10-20% get deleted via G5 or G11, <5% get tendentiously moved into mainspace by the author, sock or meatpuppets, <5% get moved into mainspace via AFC and the rest will be deleted via G13 once the time expires (but that's because I block the creators in most circumstances). A G13 deletion isn't too much of a concern - we don't want drive-by spam by non-contributors anyway. MER-C 09:58, 28 June 2019 (UTC)
  • I'm inclined to interpret this as a deletion policy by the backdoor (I don't think that's the intent, I just think that's what it is). The loss of drafts through G13 will make up such a large proportion (either no-one watching, or no-one avid enough to fix them (particularly a hoard of such)) that it would be more coherent to amend DELPOL and note that they are automatically to be refunded on request. Please note I do not advise this. Nosebagbear (talk)
I would say that if the topic is notable, but there isn't relevant or encyclopedic content it can be deleted at AfD for being promotional, even if it doesn't reach the unambiguously promotional level needed for CSD. See WP:DEL#4 Nosebagbear (talk) 11:55, 28 June 2019 (UTC)
  • I am trying to do something here for the edge cases, the ones that have some glimmer of promise. Those frequently survive AfD precisely because of that glimmer, but are then forgotten and remain in their dismal state for years thereafter. Of course, these are generally not subjects that are vital to our encyclopedia, so if they end up getting deleted as abandoned, it is not a great loss. However, it is to our detriment to keep them in mainspace perpetually, with drive-by added tags lingering, and it is an administrative burden to the project to go through deletion discussions which often resolve nothing where the solution is not going to be a binary "keep" or "delete". bd2412 T 16:10, 28 June 2019 (UTC)
Is there a reason to only apply this reasoning to articles with COI issues? Let's accept that, in some cases, pages are plagued by such serious promotional tone issues that having them visible in mainspace does more harm to readers than good (despite those pages having some small amount of redeeming content). What about an article on a notable topic that's dominated by a long-standing WP:COATRACK with no sign of improving? Or an article on a notable topic which is written like a personal essay with ruinously jumbled prose? Couldn't such articles also fall in the Goldilocks zone where the issues are so bad that the article is more likely to confuse or mislead a reader than help them, but not so bad that they'd qualify for speedy deletion (or even AfD)? Colin M (talk) 17:41, 28 June 2019 (UTC)
  • The proposal is not limited to COI, but also includes ADVERT. I see your point, but my concern is that articles in these categories are more likely to actively misinform our readers. Of course, a COATRACK problem can also be a form of advertising. At the moment, however, we only have 69 pages transcluding {{Coatrack}}, so it is on a much smaller-scale problem than more direct advertising. Also, I would clarify that COI should only be an issue where it is an undeclared COI, particularly the kind where a topic is the product of SPAs bombarding a title with promotional factoids rather than a reasonable assessment of the sources. bd2412 T 17:52, 28 June 2019 (UTC)
    • That makes sense. I would support something like this. Based on my somewhat limited experience, I can believe that the scale of the problem is large. I realize that the best solution in these cases is to just fix the problem by removing the promotional content and rewording the WP:PUFFERY, but I just can't muster any enthusiasm for spending even 20 minutes picking through sources to try to clean up an article about a borderline notable dating app/jewelry maker/music blog/whatever. I'd prefer if paid editors didn't get to profit because everyone is too apathetic to spend the time cleaning up their mess. Colin M (talk) 21:57, 28 June 2019 (UTC)
I like the idea and would support such a proposal. There are always large numbers of new articles coming through at NPP that pose the problem outlined by Colin M immediately above: not such sheer promotion that they could be CSD'd, not suitable for a jaunt at AfD because they could conceivably be cleaned up, but cleaning up would take a fair amount of (disagreeable, grudging) work and is not likely to happen in a hurry. Result, promotional content live in mainspace for an indeterminate length of time. Having a clear mandate to refer the responsibility of making these acceptable back to the creator would be most welcome. --Elmidae (talk · contribs) 17:37, 5 July 2019 (UTC)
It is already common practice for new page patrollers to draftify newly created articles that are not ready for mainspace (WP:DRAFTIFY) and they can expire there then get deleted if inactive. If I understand this would be different and recommend to do it even with older articles that have long standing COI/promotion issues, but not blatant enough for CSD/AfD? I have a concern though: there are so many and there's the issue of cross-namespace redirects and cross-namespace wikilinks not allowed when moving non-orphans (so we'd treat those links just like for deleted articles, presumably). Where to draw the line, how to evaluate? We'd probably need a few guidelines as part of the proposal... —PaleoNeonate – 21:07, 5 July 2019 (UTC)
I expect that cross-namespace redirects would be deleted, as they are with any article moved to draft. We probably would need some additional guidelines, but I think the standards would not be much different from those for moving a new article to draft space. Consider, if one article is brand new, and another of the same quality is ten years old, why should the new one be moved to draft and the old one allowed to remain in mainspace merely because it is old? Perhaps there is some greater chance that the authors of the new article will still be around to improve it, but that is not a good reason to maintain bad content in mainspace perpetually. bd2412 T 01:30, 6 July 2019 (UTC)
  • Moving to draft is equivalent in many cases to a six-month-delayed speedy deletion, with less admin supervision than the other speedy criteria. That's a no, in case there was any doubt. They are far more likely to get improved in mainspace. In my experience we need less draftifying not more. It's entirely acceptable to take any long-term tagged article to AfD if its net benefit to the encyclopedia seems in doubt. Failing that you could always try improving it. Novel approach, but it has been known to work. ETA: See for example Ntoi Rapapa (although that was moved as a BLP lacking sources) & King Billy Island which continue to exist only because I idly refreshed the G13 queue before going offline. Espresso Addict (talk) 04:04, 6 July 2019 (UTC)
    We are talking about over 30,000 articles here. Sure, they should be improved, but if the people writing them are using Wikipedia to advertise, then they should be given some incentive to clean them up other than their being a tag on the page. We have articles that have been tagged like that for over ten years. bd2412 T 14:34, 7 July 2019 (UTC)
    This seems to come down to a preference for, regarding a given notable subject, having no article until someone writes an acceptable one; versus having live a bad, promotional article, for a possibly long period. I do prefer the former. --Elmidae (talk · contribs) 17:41, 7 July 2019 (UTC)
  • Support proposal. I appreciate all the hard work editors who patrol these pages take. Pages with serious COI and advert issues that are on notable subjects and aren't suitable for mainspace should be moved to be moved to draft. Our policies and guidelines shouldn't allow COI editors to game the system. --Gonnym (talk) 14:49, 7 July 2019 (UTC)
  • There are too many of them, and too few people to fix them. I can fix about 2 a day if I do little else-- 1 a day is more realistic, which for me comes to about 25 a month, or 150 in 6 months, which is the standard time at Draft. There are probably about 20 other people who could do as much, lets suppose half of them are willing, that's 1500. Othe people who waould do a smaller about woul dprobably do at least as much as those of us willingto concentrate on it, so that's about 4,000 in 6 months. We have about 5 times that. Of course, not all will be fixable, but the only way to see that is to try--if they were obviously unfixable they swould have been deleted not tagged. But more fundamentally, this is furthermore an improper use of draft space. The criterion for promoting from draft to main space is that the article would probably pass afd. These arearticles thathave not been deleted--standard were lower in the past, but even so, probably half of them would have a decent chance of passing afd--and, if so, they should't be in Draft space.We already have a considerable amount of confusion in AfC about the proper standards for passing, and we already have a lage of about 2 months for the non-obvious drafts. All of this would be made much worse. Kudpung, and those few people of us who have been helping him over the past three years have managed to at least keep AfC/draft from being an inconsistent chaos, and this would negate all that we've been doing. DGG ( talk ) 19:03, 10 July 2019 (UTC)
  • Support At least it is one tiny step in the good direction. But more steps are needed. I have too often seen promotional articles being kept at AfD as "it can be fixed by normal editing". And then it stops and the promo stays there. The Banner talk 19:47, 10 July 2019 (UTC)
  • Support in principle, and The Banner makes a concise and valid observation. However, as DGG states, there are too many of them, and any solution requires far more examination than a binary response to the proposal. The process of NPP and AfC are closely related but are nevertheless as different as they are similar, their functions are however beginning to converge somewhat (which is what DGG and I have been striving for) at least in terms of quality and application of notability standards and deletion criteria. The main difference is that NPP is strictly a triage (and please look that up if its military meaning is not immediately clear), while AfC can and does do some very easy fixes but is still not obliged to. Nevertheless, neither system is a Field Hospital or a MASH for lazy article creators or ones who pretend not to understand our laws of creation, especially UPE and COI creators (see WP:BOGOF) - the WP:ARS is the best venue for such articles that might show some potential for surviving AfD.
The Draft namespace was created thus allowing the useless WP:INCUBATOR (where articles were left to rot indefinitely) to be deprecated. Drafts can be quasi automatically deleted G13 if they are not touched for 6 months, and this is good, but the namespace should not deliberately be used as a backdoor route to deletion.
Over the past 12 months a lot of work has been done, and for once with excellent collaboration between the community and the WMF coordinated by MMiller (WMF), myself, DGG, Barkeep49, Primefac, Insertcleverphrasehere, Kvng, Vexations, and others to modernise the two systems with new technology, and the work done at WP:Copypatrol by Diannaa and Sphilbrick.
Nevertheless it's probably too late for the 18,000 pages tagged as {{advert}}, and nearly 13,000 tagged as {{COI}} mentioned by BD2412 - we simply just do not have the peoplepower to address them, and as clearly shown by the current backlogs in both systems where for example of the 700+ holders of the WP:NPR user right, only two (yes, 2) are doing well over 90% of the work.
We need fewer minor-rights hat collectors, and more truly skilled and qualified reviewers who can work quickly but judiciously through their respective article feeds - which incidentally are now both available at the combined feed. Kudpung กุดผึ้ง (talk) 23:24, 10 July 2019 (UTC)
  • Support. This is de facto already part of the WP:Draftify as used by NPP already, at least for cases of a clear conflict of interest of the author. This is of course, not yet policy, but would be good to be codified. — Insertcleverphrasehere (or here)(click me!) 23:41, 10 July 2019 (UTC)
  • I also support this. We as an encyclopedia need to be serious about SPAM as there are huge financial incentives for people to use us in ways counter to our mission. As Kudpung points out having skilled editors make this determination while still giving time for notable content to actually be improved strikes me as a win. It also seems like this might be easier for some people if G13 were a PROD rather than a speedy but that's a different discussion for a different day. Best, Barkeep49 (talk) 23:57, 10 July 2019 (UTC)
    • I want to point out that the standard for accepting at AfC is that thearticle will probably pass an AfD.Articles that are only somewhat promotional will generally pass AfD if the subject is more than borderline notable. (It's been a major accomplishment in the last year or 2 that the ones that are borderline promotional nd borderline notable generally do not get kept--a few years ago the argument that even the borderline ones should stay and be improved in mainspace was generally accepted, and it sitll sometimes is, because AfD is by its nature inconsistent. So if we move to afc, and then they get accepted by a reviewer, who thinks they will pass, many possibly most, of them will be kept, with the cost of everyone involved doing a great deal work both at afc and afd with nothing to show for it. Remeber that anyone may assign a coii or advertising tag, whheher legitimately or illegitimately, and it is actually posssible that about 1/3 actually do deserve to stay in mainspace and be improved. DGG ( talk ) 14:09, 12 July 2019 (UTC)

D.

  • Semi-Opposed. This is just tossing a problem over the wall. Draft space is already flooded with junk, and the folks who work there are trying to fight the deluge. I'd rather see us make more liberal use of WP:G11. Note that to a certain extent, banishing something to draft space doesn't keep it out of the search engines. There's wiki-mirrors out there that grab drafts and fold them into their mirrored mainspace, which then indeed does get indexed. With less SEO-juice than directly from here, true, but I've seen mirrored drafts end up at the top of search results. The other problem with tossing the garbage into draft space is that it just institutionalizes WP:BOGOF, which is certainly not what we want. I agree that moving spam out of mainspace is a good idea (which is why I'm only semi-opposed to this), but let's not toss it into draft. Just get rid of it, either through a more liberal G11 policy, or more aggressive use of WP:AfD. -- RoySmith (talk) 14:36, 12 July 2019 (UTC)
  • Oppose - This is a bit more than tossing the problem over a wall, it is tossing a problem into a dumpster hidden over the wall. Articles are unlikely to be improved in Draft space. When they don't get improved, they get G13 deleted after 6 months. If we want to delete these, let's delete them. Feel free to convince me otherwise but passing them through draft space is just an alternate and inappropriate delete path. ~Kvng (talk) 15:30, 12 July 2019 (UTC)
  • Comment - I have another active concern about over-the-wall uses of Draft space. See Wikipedia_talk:New_pages_patrol/Reviewers#WP:NPPDRAFT_vs._AfC_acceptance_criteria. ~Kvng (talk) 15:41, 12 July 2019 (UTC)
  • Oppose per Kvng. WP:IMPERFECT is still a policy last time I checked and this proposal flies in the face of it. Even poor articles, if they can be improved, are welcome says our policy, not "Poor articles should be hidden from sight". If the subject is notable, WP:FIXTHEPROBLEM, don't hide it. If the article is completely without anything that can be salvaged, G11 already applies. If there are bits that are okay, don't remove the whole thing but just the parts that are problematic (cf WP:STUBIFY). This proposal would open the door to so much abuse because it will, as Espresso Addict rightly puts it, basically mean that they will be G13ed when nobody fixes them, which is likely most of the time, especially those articles that have been in the mainspace for years and whose creators have long left. Last but not least, it's easy to forget the reader's best interest. Someone looking about information about a subject is better served by a shoddy article than by no article at all and if interested at all, might actually use this opportunity to fix some problems they perceive. Many editors got their start by noticing something wrong or missing and fixing or adding it. We should encourage these readers to become editors and that requires keeping sub-par articles in mainspace where people can actually find them. My first attempts (back in the good old days of 15 years ago) were clumsy additions of new articles on books I liked but had no article and fixing typos and suchlike, stuff I couldn't have done if there hadn't been imperfect articles to fix. Regards SoWhy 16:38, 12 July 2019 (UTC)
  • Oppose as part of NPP, I've moved quite a number of unreferenced or very badly referenced new articles to draftspace and about 99% are just abandoned and deleted as G13 unless I make an edit to avoid G13 if I think they have potential. Moving more articles such as coi will just cause more abandoned articles in a slow deletion zombie state, and is open to abuse where articles are not overtly or even slightly promotional or have no coi are moved to draftspace and in the case of older articles where the author is no longer active no-one will notice at all, thanks Atlantic306 (talk) 22:47, 17 July 2019 (UTC)
  • Oppose Subject to abuse, I also feel that it would risk overriding an AfD in some cases - they could have draftified it, but chose not to. Sending them now would be overriding a broader consensus. I think the potential positives are over-optimistic, and heavily outweighed by the negatives. Nosebagbear (talk) 13:48, 18 July 2019 (UTC)
  • Oppose. Sending a newish article to draft is ok; there is reason to believe the person who created the article is still around keeping an eye on it and will come back wondering where it went, hopefully see the note you left them, and fix the issues before 6 months is up. Sending older articles to draft (as in this proposal) is counter-productive if we want the articles fixed. If the article is 5-10 years old and was created by a drive-by account who is no longer editing and only watched by a handful of editors, if any, sending it to draft is a 6-month death sentence. When the article is sent to draft all the categories are removed, no one hits it via the random article button, no one will ever find it, and if no one finds it, no one fixes it. Things should only be moved to draft if there is a reasonable belief that there is someone who may return and work on it. ~ ONUnicorn(Talk|Contribs)problem solving 13:58, 18 July 2019 (UTC)
  • The best solution is to delete them, which most of them qualify for in one way or another. Draftifying just becomes a 6 month deletion rather than an immediate deletion. TonyBallioni (talk) 18:12, 18 July 2019 (UTC)
    • Therein lies the rub. An advertisement disguised as an article but still meeting a low threshold of viability will evade deletion, and may go unimproved in perpetuity. Furthermore, spammers probably know this, and know how much credible content to put into an article to gain this advertising foothold. bd2412 T 03:22, 19 July 2019 (UTC)
  • Alt Suggestion Draftifying hides the deleted edits. If we want to make it easier to delete articles on commercial entities we should implement a sticky CorpProd. A bit like BLPprod, but entirely focused on independent reliable sources. Any article on a currently trading business or commercially sold product is eligible if it doesn't have a single independent reliable sources, and adding a reliable source justifies removing the tag. At the least it should force spammers to act a bit more like Wikipedians. ϢereSpielChequers 08:55, 20 July 2019 (UTC)
  • Oppose At the end of the day, it's not our responsibility to "fix" advert-filled pages. The great majority of pages meeting G11 or close to G11 need a fundamental rewrite to become encyclopedic, thus it is not going to save any work to keep them.--Jasper Deng (talk) 09:01, 20 July 2019 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_159&oldid=1091624777"