Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas. Before creating a new section, please note:
Before commenting, note:
Discussions are automatically archived after remaining inactive for two weeks. |
« Archives, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37 |
Should slave ownership be mentioned in the first sentence of articles about slave owners?
Wikipedia:Manual_of_Style/Biography#Opening_paragraph says the first sentence should include "Context (location, nationality, etc.) for the activities that made the person notable." If the subject was a slave owner should this context be included in the first sentence?♥ L'Origine du monde ♥ ♥ Talk ♥ 02:07, 13 July 2021 (UTC)
- It depends, are they most notable for being a slave holder? Then maybe. Otherwise it is likely not appropriate for the first sentence. PackMecEng (talk) 02:09, 13 July 2021 (UTC)
- I'd loosen PackMecEng's thought as "are they
mostnotable...". There could easily be major notability for something they did historically significant ("notability is not transient" and all that), but also major interest later specifically in their slave-ownership (weight of recent refs). Not for us as editors to decide which orthogonal types of notability is "most". But this aspect definitely would need to be demonstrated to be highly significant by article content that has secondary refs (WP:LEDE standard). DMacks (talk) 02:45, 13 July 2021 (UTC)- If they were the president of the United States then the answer is obviously no. The presidents did not derive their notability from slave ownership. This was explained to you repeatedly in the unanimous RfC on Washington started by you.You were reverted every time you tried to insert "slave owner" into the first sentence of every presidential bio: [1], [2], [3], etc. Please drop the stick Dr. Swag Lord (talk) 02:57, 13 July 2021 (UTC)
- I assume Dr. Swag Lord's "you" refers to L'Origine du monde (not me, as the indentation-flow suggests)? I have not been involved in the RfC or this aspect of presidents' articles in general. But looking at these details (now that I know about them, not just an out-of-the-blue VPIL brainstorm), WPIL is not the place for this. Yhe MOS talkpage would be a reasonable venue, but given the SNOW at the RfC, I agree with the STICK advice. DMacks (talk) 03:00, 13 July 2021 (UTC)
- DMacks, Yes, my apologies. I was referring to the OP. Dr. Swag Lord (talk) 03:08, 13 July 2021 (UTC)
- I assume Dr. Swag Lord's "you" refers to L'Origine du monde (not me, as the indentation-flow suggests)? I have not been involved in the RfC or this aspect of presidents' articles in general. But looking at these details (now that I know about them, not just an out-of-the-blue VPIL brainstorm), WPIL is not the place for this. Yhe MOS talkpage would be a reasonable venue, but given the SNOW at the RfC, I agree with the STICK advice. DMacks (talk) 03:00, 13 July 2021 (UTC)
- If they were the president of the United States then the answer is obviously no. The presidents did not derive their notability from slave ownership. This was explained to you repeatedly in the unanimous RfC on Washington started by you.You were reverted every time you tried to insert "slave owner" into the first sentence of every presidential bio: [1], [2], [3], etc. Please drop the stick Dr. Swag Lord (talk) 02:57, 13 July 2021 (UTC)
- I'd loosen PackMecEng's thought as "are they
- That (require this mention in the first sentence) seems like way too strict of a style rule to try to enforce across any biography. If it is significantly notable it should already qualify, but for example I don't really see why forcing that in to the first sentence for Sneferu would be necessary. — xaosflux Talk 14:15, 19 July 2021 (UTC)
- I spot-checked the first 10 entries in List of American federal politicians convicted of crimes. Only two of them (John H. Mitchell and Albert B. Fall) mention their criminal activities in the first sentence. And of course, without implying that it was ever OK, if slave ownership was not illegal at the time, then it wasn't a crime. Apparently several of our past presidents were Opium addicts [4], an activity which our society now considers illegal. Should we update the first sentence of Thomas Jefferson to include this fact? -- RoySmith (talk) 14:58, 19 July 2021 (UTC)
- Yes, plus this is not the place to raise the issue - there appears to be some WP:FORUMSHOPPING going on. Johnbod (talk) 14:54, 19 July 2021 (UTC)
- A lot of men in the past didn't respect women, or pooh-poohed their talents and ideas. For sure let's mention that in the first sentence too. The first sentence also needs to say if they gave their kids a belt once in a while, or were not nice to animals, or conquered other peoples and exploited them, or had ideas which today would be called antidemocratic.Just kidding -- see WP:PRESENTISM. EEng 03:28, 20 July 2021 (UTC)
- Only if the article subject is very notable for being a slave owner. 🐔 Chicdat Bawk to me! 10:46, 20 July 2021 (UTC)
Slave ownership is often mentioned in the lead sentence. See e.g. John Taylor (Baptist preacher) and Robert Ward Johnson. However, the mention is usually "was a planter....". "Planter" strikes me as a euphemism and I think most people won't know what it means. On the other hand, is suppose there is a difference between somebody whose income/livelihood was largely derived from slave labor (a "planter"), and somebody who owned a small number of slaves but earned most of their money through other ventures. Plantdrew (talk) 19:19, 20 July 2021 (UTC)
- No. We should place it only if the subject's main notability is his slave ownership. Kings from ancient kingdoms ranging from Egypt to Babylonians to Romans to China have slaves. Generals from those periods also have slaves, as defeated enemies will be sold as slaves. I am sure Julius Caesar is a slave owner, should we place "slave owner" on the first sentence instead of his military achievements? Should we include "slave owner" on every Ottoman sultans and Roman senators? It shouldn't be. SunDawntalk 04:52, 23 July 2021 (UTC)
- It's interesting to think that an unintended consequence of what the OP apparently wants could be to normalize slavery in the reader's mind. EEng 06:05, 23 July 2021 (UTC)
- I suspect that this proposal was meant to apply only to articles about people in the land of the free and the home of the brave.
- Some estimates indicate that this would affect about one in every 10 or 15 families in places where slavery was legal, but as owning slaves was correlated with wealth, and as wealth is correlated with notability, it would probably be a rather larger percentage of notable people.
- I'm not sure that it would "normalize slavery" so much as help readers understand just how pervasive it was. WhatamIdoing (talk) 18:10, 23 July 2021 (UTC)
- Wikipedia is a neutral source of information. If a notable historical figure was an owner of enslaved people, it is a relevant piece of information that ought to be part of the biographical article. Further, if as a consequence of mores changing the person is seen in a different light by subsequent generations of historians, then the article can and should reflect how that historical person has been viewed differently in different periods. However, whether it is written in the lead section, should be determined by whether that person is notable as an owner of enslaved people, or for some other non-related reason. The lead section, and especially the top paragraph, ought to provide insights into why that person is of encyclopedic interest; there are some people who are historically relevant because they were traders of enslaved people, for example, while others are relevant for being political leaders who would not have been notable on the fact alone of being owners of enslaved people. Al83tito (talk) 03:40, 24 July 2021 (UTC)
- It's interesting to think that an unintended consequence of what the OP apparently wants could be to normalize slavery in the reader's mind. EEng 06:05, 23 July 2021 (UTC)
- The relevant policy is WP:DUE. To echo some above, if sources considered it one of the most important things about them or that it contributed to their notability, then by all means include it in the lede. But this will usually not be the case, since owning slaves was for most of history a relatively common and mundane thing (if you had the money). As for the point about planter, I would argue that that's different as "planter" refers to an occupation and high social station (particularly in 1700s/1800s United States). "Slave owner" is as much an occupation as "car owner" and a "slave owner" could be of modest means and only own one slave, whereas a planter (if they were the slave-owning type) would probably have at least a couple dozen slaves and a fair amount of land. -Indy beetle (talk) 23:31, 30 July 2021 (UTC)
Feature Proposal: Contextual Citations
I'm interested in getting feedback for a feature I've I've been working on as a hobby. I have working code but it is alpha-quality.
The Problem:
Many people do not trust quotations in the media because they are suspicious that the quote may be taken out of context or fabricated.
Solution:
I've been developing an open-source app that:
* given a quotation which is attributed with a URL, * looks up the quote context using a Python Webservice and saves the contextual data to a JSON file * displays the context to the reader using javascript to render contextual popups or expanding blockquotes
Proposal:
* I propose that Wikipedia explore "upgrading" those quotations that are attributed to a web source to CiteIt-style contextual citations.
Benefits:
The Benefit of using Contextual Citations is that readers:
* learn more about the context of quotes * gain trust in the integrity of the citation and verify that a quote wasn't fabricated or cherry-picked.
Implementation:
You can view a video and demo on my project website:
* View Demo
More Information:
I've outlined some of the steps to implementing this on my Wikipedia User page:
* https://meta.wikimedia.org/wiki/User:Timlangeman/sandbox
Open Source License:
* All code is published on GitHub and licensed under the open-source MIT License
P.S. I'm new to the Wikipedia culture, so feel free to point out the correct Wikipedia way.
Timlangeman (talk) 03:05, 24 July 2021 (UTC)
Hi Timlangeman, thank you for your neat idea and having the tech chops to develop the code! From seeing how it works in the demonstration video, I can see this implemented in one of two ways: just as you show it, by making the quote itself clickable to bring up the contextual pop-up box, or, have this feature imbedded in the corresponding in-line citation. The question is: would this feature be used so often by readers to be it worth to make the main text clickable? Or should we minimize the "noise" in the text by having this feature a bit more discretely included within the reference? Food for thought. Thanks! Al83tito (talk) 05:35, 24 July 2021 (UTC)
Feedback Ideas: Contextual Citation UI
Hi Al83tito, I'm open to UI suggestions and I'd be happy for others to experiment with UI ideas too.
Link UI Options
As far as the amount of link "noise", this can be handled in different ways:
- style the link in a visible way
- style the link in an unobtrusive way, but still visible on hover
- remove the link and move quote inspection functionality into an icon or the footnote
Sample Articles
I don't know if you saw the 8 sample articles that I mocked up?
* 8 Sample Wikipedia Articles
These should provide good samples for programmers and designers to experiment with.
Alternate UI Designs: Programmers Download Sample Articles
I packaged these files up into a Git repository for anyone that has UI skills and wants to experiment with different UI options.
* https://github.com/CiteIt/wikipedia-samples
Feedback
If you don't have programming skills, I can create mockups based on your suggestions.
Timlangeman (talk) 14:48, 24 July 2021 (UTC)
- @Timlangeman, you might be interested in mw:New Developers. Whatamidoing (WMF) (talk:Whatamidoing (WMF)|talk) 20:30, 26 July 2021 (UTC)
- @Whatamidoing, Thanks for that suggestion. It looks like the python Wikibot may be helpful :-). Timlangeman (talk)
I like the general idea. I do have one issue however... Wikipedia generally doesn't have many direction citations. This is because of the copyright nature of Wikipedia and because it is a tertiary source. We intentionally 'transform' and 'rewrite' points from 1st and 2ndary sources most of the time and then use references. I see that as a bit of a problem for the success of this particular tool. Do you have thoughts on that ? —TheDJ (talk • contribs) 09:05, 3 August 2021 (UTC)
This is a copyright nightmare. Even the image used to demonstrate this ([5]) is probably not acceptable, as it has a way too long quote of copyrighted text. We instruct editors to make their quotes as short as possible (if the text is copyrighted, and if they can't avoid using quotes altogether): to then add a tool that shows much longer quotes simply contradicts this. For public domain sources, fine, but for copyrighted texts, I don't think this will be acceptable. Fram (talk) 09:24, 3 August 2021 (UTC)
Citation Deep Linking with Google Text Fragments
If copyright issues are a barrier to contextual citations, I'm wondering what people think about using Google Text Fragments in linking to citations to help the reader more easily inspect the context of the quote. I've written up a summary aggregating some information about them:
* Using Google Text Fragments to Link to Specific Text
I know that there are issues with browser support and privacy. At this point, I'm mainly trying to seek what people think about them in principle. Timlangeman (talk) 21:47, 5 August 2021 (UTC)
- @Mike Peel and Andy Mabbett have a talk scheduled for this weekend at Wikimania:2021:Submissions/Automatically maintained citations with Wikidata and Cite Q. They've spent a lot of time thinking about questions related to verifiability. @LWyatt (WMF), don't you have a talk about WikiCite coming up, too? Whatamidoing (WMF) (talk) 18:09, 9 August 2021 (UTC)
- Yep User:Whatamidoing (WMF) - we've got a session on Sunday. LWyatt (WMF) (talk) 14:40, 10 August 2021 (UTC)
CU policy exception for handling OS requests
Background
Earlier today I stumbled upon a help request from a user asking for suppression of the IP associated with an edit they made while accidentally logged out. The request didn't include a diff of the problematic edit (duh), but since such requests are routinely granted, I thought someone at #revdel would be able to CU the user and find the edit in question. To my surprise, this couldn't be done because our current CU policy precludes such checks.
Idea
I believe that adding an exception to our CU policy that would allow Oversighters who are also CUs to use the CU tool to expedite the handling of incomplete suppression requests would be an improvement on the current situation in which the requester is needlessly required to supply the missing information before their request can be actioned.
Global CU policy compliance
The global CU policy allows individual wikis a degree of latitude in handling self-requested checks; I believe that filing an OS request (regardless of its form) such that it requires user IP information to handle can be regarded as such a request and so the exception would be in keeping with the global policy. An argument could be made that such a check might reveal more than the user wanted us to know but this is always the case with self-requested checks and doesn't clash with the long-standing practice of allowing such, globally speaking (enwiki currently disallows self-requested IP checks wholesale).
Is this really necessary though?
I'd imagine that the typical profile of a person that inadvertently reveals their IP while logged out is that of a careless new editor. Such are notorious for being difficult to reach when a follow-up is needed which means their perfectly valid OS requests may end up rejected, or significantly delayed, due to purely bureaucratic hurdles. That sounds to me like a situation that could and should be improved upon regardless of how often this actually happens.
Mock-up phrasing
My proposed policy amendment would roughly look something like this:
As oversight requests are often time-sensitive, oversighters who are also checkusers are permitted to perform CU checks to expedite the processing of incomplete suppression requests. Information obtained through such checks may be used only for that specific purpose, and must not be shared; it also must not be retained, or even accessed, by the oversighter any longer than absolutely necessary for the handling of the request.
Is this something worth proposing at VPP? I'd appreciate some feedback. 78.28.44.31 (talk) 05:57, 26 July 2021 (UTC)
- Thing is, considering the avg response time of oversight, I don't know whether having to follow up once with the diff of the edit is a big slowdown. The delay here was because the user apparently didn't know oversight could be used for this, but usually editors would, and so they would email into the queue or email an OSer directly, presumably with the diff of the logged out edit. So I suspect this particular case is very uncommon and not worth amending the CU policy over. I'm surprised CU can't be used to actually verify the OS request though, but I suppose in most circumstances it's probably obvious from the context. ProcrastinatingReader (talk) 09:33, 26 July 2021 (UTC)
- I can't find a circumstance where material cannot be suppressed because policy somehow gets in the way. The cases such as the one mentioned above are just people not knowing or realising how to request suppression (OS requests should always be private and made with the relevant info such as an IP in this instance), and we shouldn't charge the CU policy to accommodate them. Giraffer (not) 19:28, 7 August 2021 (UTC)
A better alternative to template:convert
We encourage people to use {{convert}} so readers can see numerical values in terms that are familiar to them. A laudable goal, but IMHO, poorly implemented. For example, in Mercury-Redstone 3, we've got "His spacecraft reached an altitude of 101.2 nautical miles (116.5 statute miles, 187.5 km) and traveled a downrange distance of 263.1 nautical miles (302.8 statute miles, 487.3 km)" That's not very reader-friendly. It seems to me a better way to do this would be to have a preference people could set "I want metric units" or "I want that bat shit crazy stuff they use in the US". Then, somebody could see "His spacecraft reached an altitude of 187.5 km and traveled a downrange distance of 487.3 km". Or, "His spacecraft reached an altitude of 116.5 miles and traveled a downrange distance of 302.8 miles" for those of use who grew up in an awkward backwater corner of the universe. -- RoySmith (talk) 00:39, 27 July 2021 (UTC)
- I can see some advantages of that, but one advantage of the current system is that it exposes readers to alternative units, making them realise that not everyone uses the same units as them. The example given is pretty bad, because it gives the figure in more than two different units. Phil Bridger (talk) 08:14, 27 July 2021 (UTC)
- To help with readability, the alternate units could be in a footnote instead of in parentheses. Of course, the {{convert}} template wouldn't be used in this instance, at least not in its conventional way. —El Millo (talk) 08:20, 27 July 2021 (UTC)
- An tooltip popup would avoid having to jump-scroll all around just to see a single number in a different format, but apparently that is not accessible and/or breaks on mobile browsers and/or gives generally malformed/semantically-incorrect HTML. "His spacecraft reached an altitude of 101.2 nautical miles and traveled a downrange distance of 263.1 nautical miles." DMacks (talk) 08:50, 27 July 2021 (UTC)
- For those of us in some regions who study certain topics, different topics have different most-comfortable units. For example, US scientists would reasonably expect US geography and transportation articles would probably talk about miles between cities and degrees Fahrenheit for weather but [prefix]meters and degrees Celsius for chemistry and physics properties. And sometimes Kelvin for other chemistry/physics properties. The "main" unit to display is probably in the realm of MOS for certain article-topics and ENGVAR. Basically it's two-dimensional batshit-crazy (topical x locale). DMacks (talk) 08:42, 27 July 2021 (UTC)
- And the units can differ even in closely related topics. For example here in the UK fuel for vehicles has been sold in litres for several decades now, but its consumption is nearly always measured in miles per gallon (which, as well being in imperial units rather than metric, is also inversely proportional to the litres per 100 kilometers used in much of Europe) (and I just had another afterthought - the gallons used here are a different size from those used in the US). The "main" unit to display is in most cases determined by the source. Phil Bridger (talk) 16:39, 27 July 2021 (UTC)
- Wouldn't the preference only be available to logged in readers? The example is not reader friendly because convert isn't used in that. {{Convert|263.1|nmi|lk=in}} gives 263.1 nautical miles (487.3 km; 302.8 mi) which is much better. There are articles that should have different measurements. Most but not all airports, see the box at Heathrow Airport, measure their elevation in feet but runways in metres. While I'm happy mainly to use metric and know that 5 cm is 2 in without the use of convert I wouldn't know how long 6.3 cm is. So 6.3 cm (2.5 in) (convenient guess). CambridgeBayWeather, Uqaqtuq (talk), Huliva 01:07, 29 July 2021 (UTC)
- And the units can differ even in closely related topics. For example here in the UK fuel for vehicles has been sold in litres for several decades now, but its consumption is nearly always measured in miles per gallon (which, as well being in imperial units rather than metric, is also inversely proportional to the litres per 100 kilometers used in much of Europe) (and I just had another afterthought - the gallons used here are a different size from those used in the US). The "main" unit to display is in most cases determined by the source. Phil Bridger (talk) 16:39, 27 July 2021 (UTC)
Looking for Category:Linux distributions organization ideas
We have received complaints from readers that Category:Linux distributions is an non-navigable mess and I agree, it is. It has obviously grown up "organically", with people adding random cats over time without rhyme or reason, making it almost impossible penetrate it and actually find comprehensible lists of Linux distros.
There have been several attempts fix this, including:
- the creation of Category:All Linux Distributions (since deleted at CfD)
- the creation of Category:Independent Linux distributions (also since deleted at CfD).
- I started a discussion at Category talk:Linux distributions, but this did not attract any input at all (until @Huggums537: suggested bringing it here).
- I also started a discussion at Wikipedia:Categories for discussion/Log/2021 June 26#Category:Linux distributions, but that resulted in me being informed that "Categories for Discussion" is not the place to discuss categories, just to propose them for deletion.
- As a partial measure or first step I have made the category itself non-defusing as per WP:DUPCAT and added all the Linux distros directly to the main category itself, this at least has created a navigable list of Linux distros and partially addressed the issue. At least readers can now find things in the category and this accomplished what the editor who started Category:All Linux Distributions tried to do.
So, as mentioned, at User:Huggums537's suggestion I am bringing this here for ideas, thoughts and suggestions as to what to do about the remaining sub-categories in this category. Should they be retained, changed, or just left alone?
I duplicate here the category tree that I also posted in the CfD discussion, which diagrams the situation under discussion:
- Ahunt (talk) 00:34, 28 July 2021 (UTC)
- Ahunt, would you mind pinging into the discussion and telling us who the user is who created Category:All Linux Distributions so we could get their input as well? Thanks. Huggums537 (talk) 00:44, 28 July 2021 (UTC)
- I actually would have if I knew who they were, but since the category they created was deleted, the record is now gone (unless an admin can still see it). They did not participate in the deletion discussion, either. - Ahunt (talk) 00:51, 28 July 2021 (UTC)
- Ok, perhaps Guy Macon can divulge who they are and ping them to the discussion since he said he was aware of who the person was and that he was aware that both deleted cats were created at the same time by this same person. Huggums537 (talk) 01:13, 28 July 2021 (UTC)
- That could be helpful! - Ahunt (talk) 02:10, 28 July 2021 (UTC)
- Using Special:WhatLinksHere for the deleted cats, non-admins can find that it's probably User:Crazybpjumper who created them. DMacks (talk) 02:22, 28 July 2021 (UTC)
- Thanks. Doesn't seem likely they will contribute since they appear to have only been a single purpose account... Huggums537 (talk) 05:30, 28 July 2021 (UTC)
- Using Special:WhatLinksHere for the deleted cats, non-admins can find that it's probably User:Crazybpjumper who created them. DMacks (talk) 02:22, 28 July 2021 (UTC)
- That could be helpful! - Ahunt (talk) 02:10, 28 July 2021 (UTC)
- Ok, perhaps Guy Macon can divulge who they are and ping them to the discussion since he said he was aware of who the person was and that he was aware that both deleted cats were created at the same time by this same person. Huggums537 (talk) 01:13, 28 July 2021 (UTC)
- I actually would have if I knew who they were, but since the category they created was deleted, the record is now gone (unless an admin can still see it). They did not participate in the deletion discussion, either. - Ahunt (talk) 00:51, 28 July 2021 (UTC)
- Ahunt, if we don't attract any attention for this topic here, then I suppose another option would be an RfC to get some community input. Huggums537 (talk) 05:53, 29 July 2021 (UTC)
- I think that if no one has any ideas here either, I will just drop this issue altogether. I have recently once again gone through the whole category tree in detail and can't see anything that can be done to fix it. By the total lack of input, it looks like no one else can, either. I think by turning it into a non-diffusing category and listing all the actual distributions in it, that has solved half the problem. The other half, the sub-category tree mess, seems to be basically unsolvable, it is just something Wikipedia will have to live with (plus I am sure more will be added over time, too) so personally I am not prepared to waste any more time on it. I'll just get back to writing new articles instead, but if you want to take it further, then please do. - Ahunt (talk) 12:48, 29 July 2021 (UTC)
Countering bias
Above and other reports from Wikipedia Co founder raise questions over article bias, foreign government fake news etc. How can that be countered?
Is possible to have a pro and con page tab per subject?
With links to each disputed 'fact' so that both the pro and con view can be read by reader?
How can Wikipedia measure or show the validity or support for each point of view?
Can links to alternate points of view be included in a semi permanent way? So that biased editors are forced to acknowledge alternative narratives?
At least it might at least show on Wikipedia that entry views are 1) indispute Or 2) minority views — Preceding unsigned comment added by Ro mona lisa (talk • contribs) 14:55, 1 August 2021 (UTC)
- See Larry_Sanger#Relationship_with_Wikipedia. - Ahunt (talk) 15:04, 1 August 2021 (UTC)
- See Conservapedia. This proposal relies on the ignorant assumption that there are only two views to every historical event/political issue, and of course we know that those views are only the American political left view and the American political right view (because Sanger and the alt-right media can't conceive of anything else in this planet of 190 some countries). Where academic consensus is lacking on an issue and there a prominent debates, those are supposed to be covered appropriately. We don't always do our best to represent this, but the policies that direct us to do so are already in place. Fundamentally changing the nature of the encyclopedia to include "different views" because a group of people are upset that facts contradict their worldview would be a useless exercise. -Indy beetle (talk) 03:47, 2 August 2021 (UTC)
- Indy beetle, I think it's a little harsh to categorize a binary option as "ignorant", but I will agree that treating all issues as only having two points of view is not a good limitation. The proposal I made at Jimbo Wales talk page allows for multiple views. As an additional benefit, it allows the presentation of abuse that might not be backed up by the reliable sources required by Wikipedia. S Philbrick(Talk) 19:10, 2 August 2021 (UTC)
- Alternative theories that have reliable sources are usually included on the article. For instance, look at Malaysia Airlines Flight 370 disappearance theories or Pearl Harbor advance-knowledge conspiracy theory or Moon landing conspiracy theories. The point of Wikipedia is verifiability, not a popular contest on which theory is more well known and which one is less known. All facts in Wikipedia can be disputed, all entries can be challenged, but your "challenge" must also be reliable and verifiable.SunDawntalk 14:10, 2 August 2021 (UTC)
- Ro mona lisa, I proposed something here User_talk:Jimbo_Wales#Aggrepedia Which I hoped would generate some discussion, but this is the right place for such a discussion so I hope someone will comment. I see it as a way for Wikipedia to help deal with the bias issue. S Philbrick(Talk) 19:07, 2 August 2021 (UTC)
- Wikipedia has bias for sure. But it's not the sort of exaggerated nonsense these clickbait articles report based on nothing but someone's personal view. WP:V exists. WP:NPOV exists. WP:OR exists. Until these articles at least acknowledge the core principles of Wikipedia, we can safely ignore them as the sensationalist churnalism that they are from these supposed "reporters" that haven't bothered to do the slightest bit of research on how article with multiple viewpoints are actually collaboratively written. You know, actual journalism. — HELLKNOWZ ▎TALK 19:32, 2 August 2021 (UTC)
Hide offensive images and allow users to show them if they want to see them
There are people who find certain images on Wikipedia offensive or disturbing. It should be possible for those viewers to access the text of an article without being forced to view the images. There is community consensus that offensive or disturbing images shouldn't be censored. At the same time one fundamental goal of Wikipedia is to make information accessible for everyone. If the graphic nature of certain (e.g. medical) images shocks some users, the information on that page is in effect no accessible to those persons. In those cases, those images work against one of the fundamental goals of Wikipedia. I therefore propose that sensitive images are hidden by default, and can be displayed with a single click. If no consensus can be reached which images should be considered offensive or disturbing, I propose that all images are hidden – and not loaded – be default. This will have the additional effect of making both mobile browsing for users and hosting of Wikipedia cheaper.— Preceding unsigned comment added by 2003:df:972b:fc52:bc41:2309:e4d1:9069 (talk • contribs) 07:40, 3 August 2021 (UTC)
- There are many browser extensions you could use to not load images if you really don't want them to load; not displaying every image by default for every reader would be a big disservice. See Help:Options to hide an image for many options available. — xaosflux Talk 10:42, 3 August 2021 (UTC)
- I agree with Xaosflux. A reader who is offended by images on Wikipedia will also be offended by many images elsewhere on the Internet, so it is better to use such a general solution rather than a Wikipedia-specific one. This will also have a bigger effect on the cost of mobile browsing (if a reader is paying by the amount of data downloaded), and neither will have any appreciable effect on the cost of hosting. Phil Bridger (talk) 10:56, 3 August 2021 (UTC)
- This is not a new discussion for us. Different people have different concepts as to what is sensitive. Defining one or more criteria for offensive imagery is not a realistic task for a global community. If we hid or removed everything that anyone was offended by we would offend a bunch of people who aren't offended by human shins or female faces. So it is better that we make Wikipedia freely available to everyone, and those who don't want to see certain things can write and install their own filters, and make their own version of Wikipedia. Wikipedia is openly licensed under terms that allow for such reuse. ϢereSpielChequers 11:09, 3 August 2021 (UTC)
- If we hid everything that offended people, then people would be offended. 🐔 Chicdat Bawk to me! 11:11, 3 August 2021 (UTC)
- See the policy WP:NOTCENSORED. - Ahunt (talk) 13:07, 3 August 2021 (UTC)
- If we hid everything that offended people, then people would be offended. 🐔 Chicdat Bawk to me! 11:11, 3 August 2021 (UTC)
- Hiding all images is a good start, but to absolutely avoid offending readers, we may need to go a step further. Wikipedia is full of textual descriptions of all kinds of offensive things, such as Adolf Hitler, the Rwandan genocide, and Hawaiian pizza. These articles (even without images) could cause the reader to visualize offensive mental images. To show you just how bad this problem is, consider that our article on the human penis contains about 8500 words. If a picture is worth a thousand words, then the text on its own is equivalent to eight or nine potentially offensive images of a penis! In order to protect readers from offense, I propose that we hide all article text by default, and allow the user to click to un-hide it, paragraph by paragraph, to ensure they are definitely not offended. RoxySaunders (talk · contribs) 05:10, 4 August 2021 (UTC)
- I think a few years ago there was a large initiative to solicit the community's opinion on this matter. It was remarkably even advertised in banners on the top of pages, if I recall correctly. It was a big deal. I wish I could provide a link to that but I don't recall where to go find it. So this is indeed a very relevant issue, that was addressed in breadth and depth some time ago. Generally I think the result was to keep leaning against censorship, or even optional hiding/displaying features. Al83tito (talk) 03:34, 6 August 2021 (UTC)
- Probably one of the main discussions on this matter. See Wikipedia:Perennial proposals#Censor offensive images. The specific event you're talking about Al83tito is the m:Image filter referendum from August 2010. — Berrely • Talk∕Contribs 07:16, 6 August 2021 (UTC)
- Technically we could tag files. A simple good-bad tagging is unlikely to be sufficient. We could borrow the MPA film ratings or tag based on content like being nausea-inducing, NSFW, nudity, violence and religiously offensive. We could add a class to images (e.g. [[File:Example.jpg|thumb|caption here|class=rated_g]] though this would require changes to various infobox templates which likely can't pass classes for images. Nannyware and/or a gadget could use these classes to hide undesired image classes or only display those that are rated G/unoffensive. This would very much be opt-in as the classes wouldn't do anything by themselves. I wouldn't oppose this, but it may still prove an uphill battle to get the community to embrace this. If anyone wants to try I might be able to assist but this is isn't something I'd take on myself. — Alexis Jazz (talk or ping me) 12:47, 6 August 2021 (UTC)
- Your idea has already been proposed in the past, and evaluated as unworkable. The US-based movie rating system, for example, can be seen in other cultures as allowing ridiculous amounts of violence while being very prudish with respect to nudity. Category-based tagging might work slightly better, but keep in mind you'd need a lot of categories. "Image contains spiders", for example, to avoid offending arachnophobes. "Image contains visible women" to not offend people from some cultures (but that tagging might offend people in other cultures). And so on. Anomie⚔ 03:36, 7 August 2021 (UTC)
- The 2010 report found four general categories covered most situations for most cultures:
- extreme violence (e.g., photo of a wrestler gouging out another wrestler's eye)
- sexuality (e.g., photos of sex acts)
- religious sensibilities (e.g., Depictions of Muhammad)
- disgusting images (mostly medical conditions; e.g., the lead image at Smallpox draws regular complaints)
- With the growth of structured data about Commons images, it may someday be possible to run a script that would suppress most images of spiders (or your least-favorite politician, or whatever you felt like), but there have never been serious proposals to suppress narrow categories (e.g., only images of spiders).
- Among the objections to this that I've always found unconvincing: Vandals will add politicians to the "disgusting" list/category, it will be impossible to get consensus about whether some borderline images belong in these groups, and that unsubstantiated rumor Anomie alludes to, about someone who is allegedly very offended by photos of fully clothed women, but who still uses the internet/reads Wikipedia articles regularly. However, even if everyone was enthusiastic about it, doing it effectively would still require manually reviewing and tagging millions of images, so this would require years of work to set up plus maintenance forever. There is no quick or easy fix here. Whatamidoing (WMF) (talk) 18:38, 9 August 2021 (UTC)
- I see a script possible based on individual user input, where one user who sees an image under certain criteria will flag it, and then it will be blocked if a user opts into the filter. The list of filtered files will be hosted on an autoconfirmed-protected page, and no categories will actually be added to the images. Over time, the filter list will become very accurate. Of course, this relies on user participation and lack of conflict over the list. It may also require web hosting to confirm if a file is on the list so that users do not have to download very long lists of files. WIKINIGHTS talk 20:47, 9 August 2021 (UTC)
- The 2010 report found four general categories covered most situations for most cultures:
- Your idea has already been proposed in the past, and evaluated as unworkable. The US-based movie rating system, for example, can be seen in other cultures as allowing ridiculous amounts of violence while being very prudish with respect to nudity. Category-based tagging might work slightly better, but keep in mind you'd need a lot of categories. "Image contains spiders", for example, to avoid offending arachnophobes. "Image contains visible women" to not offend people from some cultures (but that tagging might offend people in other cultures). And so on. Anomie⚔ 03:36, 7 August 2021 (UTC)
A-Class articles
I really don't understand the A-Class article ranking. I can't remember the last time I came across one. Does it even really serve a purpose? ~ HAL333 20:41, 3 August 2021 (UTC)
- The A-Class criteria is more like a parallel ranking system. Since we have good articles and featured articles, the issue of even having an A-Class has been raised several times (see for example Wikipedia:Village pump (policy)/Archive 121#A-Class article assessment, Wikipedia:Miscellany for deletion/Wikipedia:WikiProject assessment/A-Class criteria, and several of the discussions on Wikipedia talk:Content assessment/A-Class criteria). Several Wikiprojects like having the A-class, because they can assess and promote FA-like articles on their own without actually having to open it up to the wider FA community process. Wikipedia:WikiProject Military history/Assessment/A-Class review always seems to be cited by supporters as the best formal example. On the other hand, a large percentage of Wikiprojects do not use the A-Class (which is most likely why you have rarely seen one), and instead prefer to immediately aim for the FA. Zzyzx11 (talk) 22:10, 3 August 2021 (UTC)
Changing to flat icons
I feel like this is something uncontentious as flat icons are being used all across the modern web. But still I want to build this proposal so that it is something that can reasonably be implemented.
I built a list at User:Awesome Aasim/Flat design idea - Wikipedia and @Arsonxists continued expanding that list at User:Arsonxists/Flat Icons - Wikipedia. I feel like it would be a waste of time to get community input on something uncontentious, but I still want to figure out if there is a way that we can transition to flat icons and if there is someone willing to implement this idea. Aasim (talk) 21:45, 3 August 2021 (UTC)
- Don't assume that changing icons that have massive usages will be uncontentious. — xaosflux Talk 21:53, 3 August 2021 (UTC)
- +1, also the GA icons proposal that was widely opposed. This would need an RfC I think. ProcrastinatingReader (talk) 11:48, 4 August 2021 (UTC)
- Perhaps you've forgotten the reaction the last time you proposed this? You can also search the archives for the many icon proposals, and see for yourself how many people weigh in with different views. isaacl (talk) 00:09, 4 August 2021 (UTC)
- Yes the feedback I got was "this proposal is not ready and prime yet". That is why the rfc tag was removed and that is why I withdrew. This discussion is about building a proposal for changing icons at a large scale. Aasim (talk) 02:46, 4 August 2021 (UTC)
- The feedback should not have given you the impression that a change in icons is uncontentious and doesn't require community input. (What would you propose in lieu of community input?) isaacl (talk) 04:50, 4 August 2021 (UTC)
- In fact, to quote Izno:
I do not think this question is ripe for an RFC. I see no recent discussion and I certainly see no major significant dispute needing resolution. I see a lot of "we should do this" but not a lot of "here's my solution".
This is the drawing board, this is the place to figure out how the proposal should be done before it is proposed again via RFC. Aasim (talk) 09:00, 4 August 2021 (UTC)
- In fact, to quote Izno:
- The feedback should not have given you the impression that a change in icons is uncontentious and doesn't require community input. (What would you propose in lieu of community input?) isaacl (talk) 04:50, 4 August 2021 (UTC)
- Yes the feedback I got was "this proposal is not ready and prime yet". That is why the rfc tag was removed and that is why I withdrew. This discussion is about building a proposal for changing icons at a large scale. Aasim (talk) 02:46, 4 August 2021 (UTC)
- Nowhere in Wikipedia guidelines or policies does it say that things should be done because they are modern or trendy, or for some reason have to be changed even though Wikipedia has only been in existence for just over 20 years. This can only be considered if you tell us some genuine benefits that changing icons brings rather than such fripperies. And claiming, after your previous such proposals, that such a change would be uncontentious is simply mind-boggling. I'm afraid it loses you any credibility that you might have had. Phil Bridger (talk) 05:28, 4 August 2021 (UTC)
- I think this is more about graphic design; these templates are visible to readers of any page all over Wikipedia. While most readers could care less about these templates, they probably could care more about how a page looks if they were to say, screenshot it or print it out. The last thing we want is that in a decade or so, Wikipedia looks like a site from thirty years ago in 2030. Having non-flat icons like File:Information icon4.svg could possibly degrade from that look. I know WMF is working on a new and improved vector skin with features like responsive design so that Wikipedia can look as modern as it can possibly be. Changing the icons to flat icons would help with this move, especially because almost every modern website from wikiHow to FANDOM to Google and Facebook uses flat design, and websites that do not use flat design look very old and archaic. Aasim (talk) 08:57, 4 August 2021 (UTC)
- I, for one, am perfectly happy with a web site that looks 20 or 30 years old, which, by the way, isn't anywhere near archaic. We're an encyclopedia, not some super-duper fun app for right-on teenagers, so that is the type of look we should be going for. Phil Bridger (talk) 09:05, 4 August 2021 (UTC)
- That is not to say that others may or may not find it engaging. What kind of boggles my brain is that MediaWiki wiki was able to switch over the icons with no problem, but here we have this kind of debate over if or whether these icons should be switched.
- The web is also moving on; you no longer see as many websites that have "mobile versions" of websites under an "m" domain and you see more websites that just adapt to all screen sizes. This idea has nothing to do with responsifying Wikipedia's skin. That is already being done by WMF. It is just about the icons in Template:Mbox.
- Another thing to consider is load times. Take for example, File:OOjs UI icon information-progressive.svg (
) and its non-flat counterpart File:Information_icon4.svg (
). From my understanding, all the rendering happens on Wikipedia's servers then sent to the browser. The file size of the non-flat icon at 40px is three times bigger than the OOjs-UI flat icon. Not sure if it is a significant impact compared to the size of some of our pages being 150KB, but when loading something on your mobile phone or on a poor Internet connection, every single byte matters.
- And yes, we are an encyclopedia. I am not doubting that. This is just an idea in the works. If proposed correctly, it is possible for some to say "you know what, yeah, this is a good idea." or for people to be indifferent to the change, rather than people complaining that "the newer modern interfaces are harder to use" as TransporterMan put it. This is not about the UI for Wikipedia. Just the icons. Should have made that clear.
- I'll probably work on finding suitable flat alternatives to each of the icons that could be changed that are easy to understand to build this idea, but I do not think there will be a set timeline. My understanding of flat design is that it is supposed to feel less clunky and cluttered and easier to understand compared to skeuomorphic design. Maybe it is just personal preference that I prefer the flat version of icons. I don't know. (On a side note: We already redid our protection icons to something flat mainly because the non-flat padlocks were difficult to understand for someone with color blindness.) Aasim (talk) 10:46, 4 August 2021 (UTC)
- Now you are starting to give valid reasons for changing the icons, such being less clunky and offering better accessibility. Being more "modern" or following the herd to look more like Google and Facebook are not valid reasons. The first is neutral and I would say that the second is negative. We should be distinguishing ourselves, not looking like other sites, and setting the trends, not following them. Phil Bridger (talk) 10:55, 4 August 2021 (UTC)
- Agreed. I think the real reason for making a switch to an icon is to make us Wikipedia look professional. That is also why we have rules as to what is allowed on user and talk pages and what is not.
- From an accessibility standpoint, some design decisions made by flat web designers actually impeded usability, for example by removing cues that a link is clickable. Fortunately, Wikipedia has not done that. I think there are probably good reasons that Microsoft, Google, Apple, then Facebook moved towards a more flat interface that goes beyond looks and trends. That is what I haven't figured out yet lol. Aasim (talk) 11:14, 4 August 2021 (UTC)
- @Awesome Aasim: the community on "MediaWiki wiki" is very very small, and is primarily comprised of technical-minded editors, and their readers are primarily there looking for documentation. It is certainly not representative of the community or readership of large content projects such as the English Wikipedia. — xaosflux Talk 13:21, 4 August 2021 (UTC)
- Now you are starting to give valid reasons for changing the icons, such being less clunky and offering better accessibility. Being more "modern" or following the herd to look more like Google and Facebook are not valid reasons. The first is neutral and I would say that the second is negative. We should be distinguishing ourselves, not looking like other sites, and setting the trends, not following them. Phil Bridger (talk) 10:55, 4 August 2021 (UTC)
- I, for one, am perfectly happy with a web site that looks 20 or 30 years old, which, by the way, isn't anywhere near archaic. We're an encyclopedia, not some super-duper fun app for right-on teenagers, so that is the type of look we should be going for. Phil Bridger (talk) 09:05, 4 August 2021 (UTC)
- I think this is more about graphic design; these templates are visible to readers of any page all over Wikipedia. While most readers could care less about these templates, they probably could care more about how a page looks if they were to say, screenshot it or print it out. The last thing we want is that in a decade or so, Wikipedia looks like a site from thirty years ago in 2030. Having non-flat icons like File:Information icon4.svg could possibly degrade from that look. I know WMF is working on a new and improved vector skin with features like responsive design so that Wikipedia can look as modern as it can possibly be. Changing the icons to flat icons would help with this move, especially because almost every modern website from wikiHow to FANDOM to Google and Facebook uses flat design, and websites that do not use flat design look very old and archaic. Aasim (talk) 08:57, 4 August 2021 (UTC)
- Leaving aside the problems that others have already pointed out, I also note that most of those icons are under the Expat license. That license includes a clause that "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software", which means we need to maintain the link to the file description page to satisfy that requirement. It would be better if you'd select icons that are public domain or CC0 as people tend to like to suppress the link. Anomie⚔ 11:13, 4 August 2021 (UTC)
- Even more interesting... although I think that may apply if we were to use all the icons or if we were to duplicate and modify the software that generates and uses these icons [6]. The majority of the icons would be too simple to be copyrightable anyway, given that they are below the United States threshold of originality, so I would not see how omitting a link would be a problem. The main reason for using the OOjs icons in particular (which is separate from using flat icons) would be that this is what MediaWiki software uses, and people like the right mix of novelty and familiarity. They have probably seen these icons on MediaWiki or when they were looking for some button on mobile or when they were using the VisualEditor. Aasim (talk) 11:26, 4 August 2021 (UTC)
- That's a lot of assumptions. The licenses on the individual images don't depend on using "all" of them or on whether we're modifying software. If they're too simple to copyright, then they should be labeled as public domain rather than Expat (but not all of them are too simple). How many people actually use mediawiki.org, or pay attention to icons in mobile, or VE? Anomie⚔ 11:40, 4 August 2021 (UTC)
- Even more interesting... although I think that may apply if we were to use all the icons or if we were to duplicate and modify the software that generates and uses these icons [6]. The majority of the icons would be too simple to be copyrightable anyway, given that they are below the United States threshold of originality, so I would not see how omitting a link would be a problem. The main reason for using the OOjs icons in particular (which is separate from using flat icons) would be that this is what MediaWiki software uses, and people like the right mix of novelty and familiarity. They have probably seen these icons on MediaWiki or when they were looking for some button on mobile or when they were using the VisualEditor. Aasim (talk) 11:26, 4 August 2021 (UTC)
- I took a look at the suggested flat icons. To my eye, they look cartoony and amateurish - not professional at all. So… while this is not a “never” !vote, I have to say “no”. Blueboar (talk) 12:02, 4 August 2021 (UTC)
- Cartoony? I don't think so at all. A simplified icon doesn't look "cartoony".
The main problem is that most Wikipedia editors brand themselves as knowing what's "best for the readers". I've always wanted to change the FA icon to File:Symbol star gold.svg, but I'm sure that'd be met with huge criticism where "the current FA icon is iconic to readers" or "what's the problem with the current icons?". By the time Wikipedia actually changes it's icon style to something consistent and usable there'll be some new style that makes this look outdated. — Berrely • Talk∕Contribs 13:27, 4 August 2021 (UTC)- You have explained there quite accurately why Wikipedia should not attempt to follow trends. Only people who are interested in such shallowness worry about things like looking "outdated". And I can't for the life of me imagine how avoiding such ignomony benefits readers. I wish people would get into their heads that most people couldn't give a fig about the latest fashions in graphic design. Phil Bridger (talk) 14:17, 4 August 2021 (UTC)
- It's not about whether "it's the latest trend", Wikipedia will always be outdated and there's no changing that :). However there many advantages to using simplified icons. Especially at smaller scales the details of these icons, such as drop shadows and gradients, disapperar completely and often make it harder to understand what the image is. Consistency is also important. Wikipedia amboxes, messages and other notices all use a wild array of barely consistent icons (we do seem to use the Tango set most commonly). These icons are already being used in parts of Mediawiki, such as the mobile site and the newcomer's homepage. It's much easier to quickly understand an icon when you have seen an icon similar to it before. — Berrely • Talk∕Contribs 16:20, 4 August 2021 (UTC)
- You have explained there quite accurately why Wikipedia should not attempt to follow trends. Only people who are interested in such shallowness worry about things like looking "outdated". And I can't for the life of me imagine how avoiding such ignomony benefits readers. I wish people would get into their heads that most people couldn't give a fig about the latest fashions in graphic design. Phil Bridger (talk) 14:17, 4 August 2021 (UTC)
- Cartoony? I don't think so at all. A simplified icon doesn't look "cartoony".
- Agree that those proposed icons looks very cartoonish. Not at all what an encyclopedia should look like. --Khajidha (talk) 18:31, 4 August 2021 (UTC)
- I'm not opposed to updating or replacing some of the icons in principle (I do really like the idea of swapping FA's to that star icon Berreley mentioned, it fits much better with the good article icon), but I'm not sure that these are really the set to replace them. They don't really seem to work as a set to me. Some specific feedback:
- With the minimalist sans-serif font it's difficult to tell the difference between "shape with an i indicating information" and "shape with an ! showing a warning".
- Why do the normal deletion and speedy deletion message boxes now have different icons? They both warn of impending deletion.
- with the original clean-up templates the different icons made it clear what issue each issue addressed - brush for tidying, blue i for information, orange ! for issues. With the new icons this information has been reduced entirely to colour, and I don't think it would be obvious to readers that a yellow dot means "minor clean-up" or an orange dot means "content issues".
- Why does the level 3 user warning template use a completely different design, colour scheme and font compared to all the other icons?
- Why is the "on hold" icon a yellow information sign? Wouldn't a clock make more sense for waiting?
- Why has the stop question mark changed shape? I thought the whole point of that icon was that it looked like a stop sign.
- Regardless of my thoughts on this set of icons any change is not going to be a "minor" alteration, and will certianly require a rfc advertised on cent. If I were to be proposing it I would do it one set of icons at a time, I think you would have a better chance of ending up with some kind of consensus rather than a trainwreck. 192.76.8.91 (talk) 21:03, 4 August 2021 (UTC)
- Take a look at the colored clock icons that exist for the {{unblock}} template:
- Per MOS:ACCESSIBILITY and web accessibility guidelines, we should never exclusively use color to communicate information, as people who are color blind cannot distinguish at first glance what these icons mean, especially for those with red-green and blue-yellow color blindness at best and full color blindness at worst. That is why the padlock icons were changed to begin with to include more visual information. The three icons that I am suggesting replace this as I build my proposal are easy to understand at first glance as to what they mean, if someone scrolls past and just sees "unblock" at the top of the page:
- These icons will fit the unblock template fine, although someone could possibly modify File:OOjs UI icon pause.svg so that it is available in yellow.
- And about the icons looking too cartoonish: I disagree. These icons are flat, like what flat design is. An example of a cartoonish icon would be this. Aasim (talk) 23:40, 4 August 2021 (UTC)
- @Awesome Aasim: So firstly, just to pile on the above, this is absolutely controversial and given your involvement in previous efforts it's beyond me how you could think it didn't need community consideration. Beyond that, while your example of cartoonish is definitely that, it also is an example of picking something that's an ultra-example of such so as to be able to state that examples less far along the spectrum don't belong in the same bucket. I also feel that your examples do look cartoonish, and would want to see better examples before supporting them. I do generally support efforts to include non-colour information in - and in that specific sense, ones in a similar vein to your examples could be a good shift if, and only if, you can resolve the other issues. Nosebagbear (talk) 23:58, 4 August 2021 (UTC)
- I don't know why I thought this would be uncontentious either 🤷♀️
- About the cartoonish icons, maybe it would be better to visualize what some of the templates would look like with these icons, and we could go from there. If I can find a better set of icons, that would be excellent. I'll take that into consideration. This is the idea lab, after all :) Aasim (talk) 00:02, 5 August 2021 (UTC)
- And to counter the argument that the icons are too cartoon-y: These icons have already been in use on mboxes on mobile: An American in Paris - Wikipedia. Since they already have widespread use on the mobile site, why not expand it to desktop? Aasim (talk) 00:47, 5 August 2021 (UTC)
- So, you are saying that because someone else did something stupid, we should too?--Khajidha (talk) 00:55, 5 August 2021 (UTC)
- Stupid or not stupid is subjective. I think consistency is also important; our current icons are mostly inconsistent with mobile and the rest of the MediaWiki interface.
- And remember that this is the idea lab: it is the place to work on proposals before sending it off to community consensus. And how can we comment on a specific icon when we cannot visualize its potential use? Unlike the Padlock RFC, which was easy to visualize since the icons can clearly be seen in the corner of every page, most of these icons that I am proposing to be changed are used in message boxes, interface messages, and the like.
- One important thing is form follows function, something that the unblock request clocks in my above example does not follow. For someone who is fully color-blind, it will look like something is pending, rather than declined or accepted. Hell, even I would see something like this as pending if I were a new editor and did not understand what the colors for the block clocks meant. A check mark reads as "done", an ex mark reads as "not done", a clock reads as "pending", and that OOUI pause symbol reads as "on hold".
- I think one thing to aim for is consistency across the board: I maybe propose a few different icon sets (some which are PD instead of CC or MIT) that we could use on Wikipedia, and whichever icon set is more popular we just fork and modify for use on Wikipedia's messages. We also want to make sure that the messages communicated by the icons are the messages we intend to communicate. Aasim (talk) 01:35, 5 August 2021 (UTC)
- I don't think you'll get very far with an argument that we should be consistent with the weird hacks that they've done in the mobile site, given all the other hugely bad ideas they've implemented in the past (often in the name of "design") like hiding the existence of talk pages from mobile editors. Anomie⚔ 12:41, 5 August 2021 (UTC)
- I think we should start by examining the question of whether we even should use these icons. --Khajidha (talk) 19:14, 5 August 2021 (UTC)
- So, you are saying that because someone else did something stupid, we should too?--Khajidha (talk) 00:55, 5 August 2021 (UTC)
- @Awesome Aasim: So firstly, just to pile on the above, this is absolutely controversial and given your involvement in previous efforts it's beyond me how you could think it didn't need community consideration. Beyond that, while your example of cartoonish is definitely that, it also is an example of picking something that's an ultra-example of such so as to be able to state that examples less far along the spectrum don't belong in the same bucket. I also feel that your examples do look cartoonish, and would want to see better examples before supporting them. I do generally support efforts to include non-colour information in - and in that specific sense, ones in a similar vein to your examples could be a good shift if, and only if, you can resolve the other issues. Nosebagbear (talk) 23:58, 4 August 2021 (UTC)
Really, what do we know?
Maybe we should take a different approach. What happened to readers' input? After all, readers are the ones who are using Wikipedia, we are modifying it: WP:CREEP strikes again. User:Berrely made a good point: We don't know much about our readers. Maybe our readers are Gen Z teenagers. Maybe our readers are scientists who understand jargon. What do we know?
Is there some way we can poll our readers to see what they want? If this has been tried before, don't heckle me, come up with a better solution. Sungodtemple (talk) 14:30, 5 August 2021 (UTC)
- I'm sure somewhere in one of the hundreds of research papers about Wikipedia that are released every year, there's something like this. A poll or survey could be interesting, but I'm sure if something like that were to go through it would require coordination with WMF on how to do it, as well as people generally wanting to use it again. It's no simple feat.
I just know that most people I know prefer icons that are clean and consistent. I do agree some of these icons are oversimplified or inappropriate, why is speedy a different icon? Why is the unblock on hold icon not a clock? However, I disagree that some icons are too hard to understand, e.g. this is much better than this at a low resolution.
The real answer is that we don't know what most readers want. Me asking a few people certainly doesn't represent everyone's view. However I definitely do know the simplicity and consistency are very important, especially when it comes to icon design. — Berrely • Talk∕Contribs 15:04, 5 August 2021 (UTC)
Political positions bloat in articles of politicians
If you use Wikipedia to stay informed about current politics and elections, you will be used to articles of politicians being filled with sections about their political positions. Such sections are often divided into sub-sections about specific issues and may become very long. It seems that editors will indiscriminately add a politician's statement about their political position as long as there is RS (usually news) to substantiate it. I have noticed this problem in the English-speaking countries of the US, the UK, Canada, and Australia, and it may extend to virtually every democratic country. It also extends beyond government officials, elected or unelected, to political commentators and others who are involved in politics.
Political positions bloat is unencyclopedic, excessive detail, recentism, and cruft. Remember that Wikipedia articles are summaries of their topics, not treatises, not essays, not voter guides. While politicians generate a lot of media coverage (which would be considered routine coverage in the terms of our notability guides), we do not consider every detail mention-worthy, unless it happens to be a political position. Why would we include a low-profile comment someone says about, say, marijuana, but not if they own a dog? Both will not be remembered in the long term.
The salience of political issues constantly changes, and politicians will become known for a few accomplishments or ideological opinions. Lists of political positions will not pass the 10-year test, but summaries and generalizations will. We should not include such lists for pre-21st century politicians because we are aware of what they are notable for and what is a side detail. Indeed, we find sections discussing the political positions of dead politicians, though they are not bloated with details of minor political issues. In reality, that is because the Internet and the existence of Wikipedia have enabled the expansion of lists in gradual steps. One may object that we do not know which political positions are relevant. But even without the certainty of scholarship, we should recognize what is noteworthy based on how much attention some position has garnered in RS, just as we recognize which details of personal life are notable and which are not. It is especially useful when a source explicitly states that someone is known for something.
I propose a link-able essay written on this issue (Wikipedia:Political positions, WP:POLPOS as a link?) and hope that we can soon cut down on political views sections. WIKINIGHTS talk 13:19, 9 August 2021 (UTC)
Vandalism/good-faith edit warnings should link to diff
Idle thought: {{uw-van1}} etc really ought to link to a specific diff when they can. Enterprisey (talk!) 07:46, 10 August 2021 (UTC)
- It makes it easier for others to see what the warning is about. And may make it easier to find inappropriate warnings. However it is too much trouble for warners to do, and it is extremely likely that the recipients know what the warning is about. So Enterprisey, I suggest that you go through all the warnings on users' talk pages and find the diff that led to it. I guess you will find it to be a waste of time. Graeme Bartlett (talk) 12:02, 10 August 2021 (UTC)
- We would need to change the automated tools that place these warnings; asking patrollers to find specific revids would certainly be a waste of time. Enterprisey (talk!) 21:40, 10 August 2021 (UTC)
- There's already an article parameter for the template, but not a diff template. I agree it'd be nice if we could get some of the warning tools to add one automatically. A wrinkle is that sometimes the warning will be for multiple edits on a page. {{u|Sdkb}} talk 22:17, 10 August 2021 (UTC)
- Yeah, needless to say in that case we'd just go with the current behavior. But I'm pretty sure we could get a decent user experience improvement out of this nevertheless. Enterprisey (talk!) 06:56, 11 August 2021 (UTC)
- Ikr. So much of this website seems to run on... manual paperwork, for things that could easily be automated with structured data. Intralexical (talk) 15:40, 11 August 2021 (UTC)
Bold idea: the Generic Queue Toolkit
Wikipedia has a lot of queues. Two disparate examples: WP:AFC/R and WP:PERM. What if we made them all use the same technology? I have a vision. If you write a JSON page that has the following information:
- Questions to ask requesters, and request instructions (like the "Before applying for approval" section at Wikipedia:Bots/Requests for approval/Instructions for bot operators)
- Templates to add to the request (like the toolbox available at PERM)
- Possible outcomes (templates the responders could use, like those listed at {{BAG Tools}})
- Whether each request gets a new section, or a new subpage (OK, this one's a bit ambitious - let's only support the "new section" workflow for the first version)
You should get:
- A nice form requesters can fill out (like the WP:DRN form - click "Request dispute resolution" for an example)
- A page where new requests go (of course)
- A nice user script to respond to requests (could look like the WP:AFC/R script, or any number of the other request-response scripts we have)
- Nice archives
Problems this solves:
- Not having to maintain a new "form script", "response script", and archival process for each darned queue. (This is really big. Most people don't notice this. Being the maintainer for one of these, I really notice it)
- We can improve the user experience for every queue simultaneously
- Users don't have to fill out a wikitext form, one of the more user-hostile things we still have
- Responders don't have to respond by clicking "Edit section" over and over and over
Queues this could apply to, off the top of my head: DRN, BRFA, PERM, AFC/R (probably more)
Anyway, if anyone wants to help out, let me know here. This might be a bit of a heavy lift, but I'm sure it's worth it, and I know a thing or two about graceful and peaceful transitions of Wikipedia processes to newer technology. Enterprisey (talk!) 07:10, 11 August 2021 (UTC)
- @Enterprisey: I could probably help you with this. TheTVExpert (talk) 21:04, 11 August 2021 (UTC)
Deleted section aggregator?
Are there any tools that can automatically find and display sections that used to be in an article but have since been deleted?
I think this might unfortunately be the most insidious form of vandalism. Disinformation isn't terribly hard to spot, verify, and remove, but sourced material that has been removed can't be seen again unless you go digging through the page's history for some reason. Intralexical (talk) 15:42, 11 August 2021 (UTC)
- @Intralexical: Edit filter 172 automatically tags all edits that remove a section as "section blanking". You can have a look through the filter log or you can sort recent changes to show only tagged edits, see here. 192.76.8.91 (talk) 18:02, 11 August 2021 (UTC)
- @192.76.8.91:. Hm. Cool. Clunky, though. I guess it could be useful as an scraping/API endpoint for generating a more robust display. Intralexical (talk) 21:03, 11 August 2021 (UTC)