Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page

New proposals are discussed here. Before submitting: Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ. Consider developing your proposal at Village pump (idea lab). Proposed policy changes belong at Village pump (policy). Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals. Proposed new wikis belong at meta:Proposals for new projects. Proposed new articles belong at Wikipedia:Requested articles. Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF). Software changes which have consensus should be filed at Phabricator. Discussions are automatically archived after remaining inactive for nine days.

« Archives, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173

Centralized discussion

Village pumps:policy•tech•proposals•idea lab•WMF•misc

• RfC: Shooting or Death or Killing or Murder?
• meta: Universal Code of Conduct: review of draft
• Must volunteers declare they are paid editors?
• Reliability of Mail on Sunday
• Should paid editors have to use AFC?

---

For a listing of ongoing discussions, see the dashboard.

• view
• edit
• history
• watch
• archive
• talk

Succession boxes for US Presidents

Following on from the discussion started here:

Talk:Donald Trump#What happened to the succession boxes?

How does the community feel about succession boxes and their inclusion in the articles about US Presidents specifically? The following three options were presented on the talk page above:

1. The succession boxes should be included in all U.S. presidents' BLPs.
2. The succession boxes should be omitted from all U.S. presidents' BLPs.
3. One size does not fit all. Cross-article consistency is less important than flexibility. Decide on a case-by-case basis at article level.

I genuinely believe they help navigation between articles, though they could often be trimmed down to avoid trivial items, and if they are too large, they can be collapsed into the Offices and distinctions box. That way if you are looking for them, they are there, but if not they are not taking up a lot of space at the bottom of the article. ScottishNardualElf (talk) 08:55, 1 September 2020 (UTC)

• 2 - The information therein is somewhat redundant with the Preceded by and Succeeded by fields of {{Infobox officeholder}}, while far less visible and accessible being at the bottom of the article. What little anecdotal evidence we have (from editors who used to be only readers) suggests that readers rarely or never use the succession boxes. At Donald Trump, the boxes were removed after brief discussion in December 2018, and the only arguments in opposition to that have been that U.S. presidents' BLPs must be consistent. No one has even attempted to make the case that the boxes actually benefit readers enough to justify the space required, and I feel that would be a very difficult case to make. Ok, so let's make U.S. presidents' BLPs consistent. ―Mandruss ☎ 09:26, 1 September 2020 (UTC)
• 2 - succession boxes are such an outdated navigation tool on en.wiki. We have as Mandruss pointed above, the relevant fields in the infobox, but also navigation templates such as {{US Presidents}} which already show the entire list. Succession boxes just add clutter as they are much more larger and offer no additional value. --Gonnym (talk) 10:28, 1 September 2020 (UTC)
• 1 or 2 - but this should include all the US presidential & vice presidential nominees bios. GoodDay (talk) 14:16, 1 September 2020 (UTC)
• 2 seem pretty redundant/useless now. We show the same information in better ways in articles. Showing succession for the Nobel Peace Prize (ref Obama) is not helpful. Succession for major office posts is already shown in infobox. I support broader removal from all such articles. Also noting that cobaltcigs's mockup below is a significant improvement, and in any case the boxes should be updated to that if kept. ProcrastinatingReader (talk) 13:50, 6 September 2020 (UTC)
• 2 I think succession boxes in general have had their day. The infobox is much more useful, because it puts the short summary of the individaul write at the top of the article. If an individaul has a lot of offices that wouldd make the infobox too long, it's always possible to put some of the offices in a collapsed format, as is done with the infobox for John A. Macdonald. --Mr Serjeant Buzfuz (talk) 17:32, 7 September 2020 (UTC)
• 1 – Succession boxes remain useful for cases where the inclusion of an office in the infobox of a given article wouldn't meet MOS:INFOBOXPURPOSE. For example, in the Canadian context, it's not uncommon for there to be "secondary" ministerial titles that are typically held alongside a more significant portfolio, such as Minister responsible for La Francophonie. Despite being a significant office, it simply wouldn't be important enough to include in the infobox in most cases. 207.161.86.162 (talk) 05:38, 15 September 2020 (UTC)
• 1 Not sure where you're getting "anecdotal evidence" from. I use them all the time for navigation. Perhaps among the most useful things on a page, particularly if a person has held multiple offices or secondary titles over their lifetime. The infobox at the top is not always the clearest nor complete, and sometimes troublesome to scroll all the way back up there if you're already at the bottom. Walrasiad (talk) 07:41, 17 September 2020 (UTC)
• 1 I've found them very useful for navigating articles. PaleAqua (talk) 18:08, 5 October 2020 (UTC)

Flatten your succession boxes and/or abs

So I've suggested this before but here is my initial visual mock-up. What we know today as "succession boxes" should be flattened out to look roughly like this:

Ideally the template would also read each row's data (names, order, dates, annotations, whatever) by looking up {{PAGENAME}} on centralized lists (titled e.g. Module:Succession/President of the United States) and format the lookup results accordingly. So the calling syntax might be reduced to something like this (with various shorthand abbreviations allowed):

{{succession navbox|Illinois Senate|United States Senate|President of the United States}}

Unrecognized positions such as Community Organizer (Chicago) would be ignored and impossible for noobs to casually add. Such a system would greatly reduce screen waste, allow tighter control over accuracy, and protect against the random crap that existing succession boxes universally attract. I could probably create it within a few days, if there is interest. ―cobaltcigs 12:11, 1 September 2020 (UTC)

Considering that the existing boxes are collapsed, I don't think this is really relevant to this discussion (and it feels like a bit of a distracting hijack, to be honest). From what I've seen, the arguments against the boxes are not that they occupy too much screen real estate when temporarily expanded by a reader. There is no reason to believe that this would be more needed or used than the existing boxes. ―Mandruss ☎ 12:38, 1 September 2020 (UTC) (Strike after subsequent discussion.) ―Mandruss ☎ 13:35, 1 September 2020 (UTC)

Perhaps User:Gonnym would clarify Succession boxes just add clutter as they are much more larger in light of the fact that they are collapsed, but my reference to the space required was about other types of space: File size, post-expand include size, space in the edit window, and even the screen space required for the collapse bar. If the boxes are rarely used, even those relatively minor things are unjustified. Massive unnecessary clutter is usually a gradual accumulation of relatively minor things just like this – "hey, one more collapse bar won't hurt" – and we can only address them one at a time. ―Mandruss ☎ 13:03, 1 September 2020 (UTC)

A template shouldn't be huge even when expended if it doesn't need to. Compare the size of the succession section (Offices and distinctions) to Template:Barack Obama. Look at how much link data the navbox has compared to the succession one and yet the succession one is much larger and duplicates information presented elsewhere in the article, including right next to it with {{US Presidents}}. --Gonnym (talk) 13:17, 1 September 2020 (UTC)

@Gonnym: In that case, cobaltcigs's proposal would appear to address at least some of your concerns. Would you support it as a solution, then? ―Mandruss ☎ 13:23, 1 September 2020 (UTC)

No, not really. It is better than the current succession templates, but it's still not needed as it's still duplicating data right next to it. Using the above example, it's duplicating {{US Presidents}} and {{United States senators from Illinois}} with the 13th District seat seemingly not being important enough to warrant a navigation template. And again, all 3 are the first pieces of information right after his image in the infobox. --Gonnym (talk) 13:30, 1 September 2020 (UTC)

Fair enough - I am still learning the ropes here. ScottishNardualElf (talk) 22:25, 1 September 2020 (UTC)

@ScottishNardualElf: You might get more attention on this topic, if you make this discussion an RFC. GoodDay (talk) 15:33, 3 September 2020 (UTC)

So this proposal was actually intended as a compromise between the status quo and my (unpopular, I thought) personal opinion that totally getting rid of succession boxes would be better. Support for the latter seems higher than predicted, which is good. As long as we whack the {{portal bar}}s next. ―cobaltcigs 22:18, 10 September 2020 (UTC)

@Cobaltcigs: If you support option 2, feel free to indicate same in the preceding section, for clarity. ―Mandruss ☎ 15:14, 11 September 2020 (UTC)

• I think the idea of flattenning the boxes is the best idea--and possibly not just for US presidents but in general. They're a rather primitive visual element, reminiscent of the earliest years of html. The basic information they give is useful--the prominence in the appearance of the article dadds nothing to that. DGG ( talk ) 00:55, 19 September 2020 (UTC)
• Broadly support flattening but the sample doesn't work well without some kind of separator in a wide window (and particularly as the number of offices rises). If the middle column could be made relatively narrow, and the left and right columns were right and left aligned respectively it would keep things visually connected ^~Hydronium^~Hydroxide^~(Talk)~ 02:28, 19 September 2020 (UTC)

Expansion of scope: succession boxes

This question should be expanded to include all the US presidential & vice presidential candidate bios. GoodDay (talk) 14:13, 1 September 2020 (UTC)

Sure, but why stop there? What about use of the same boxes in the BLPs for other U.S. officeholders? What about non-U.S. officeholders? If you're expanding scope at all, the only logical place to stop expanding would be to include all uses of the boxes anywhere in the encyclopedia. That's a far larger question, and before you know it you have a months-long discussion, very possibly all wasted time due to a no-consensus outcome. I say we can take this on in smaller pieces without undue harm to the encyclopedia, but any consensus here would be a factor in future discussions about other pieces. If we reach a consensus for option 1, there probably won't be any future discussions anyway. ―Mandruss ☎ 14:44, 1 September 2020 (UTC)

It wasn't my decision to delete the succession boxes at Donald Trump, thus putting that article out-of-sync with the others. GoodDay (talk) 15:38, 1 September 2020 (UTC)

That again??! You're right, it wasn't your decision. It was a local consensus not precluded by a community consensus, as explained to you more than once. The cross-article consistency factor was argued, and it was not enough to sway consensus toward keep. Please cease making me keep explaining to you how Wikipedia works, you have been around far too long for that. You are becoming disruptive. ―Mandruss ☎ 15:49, 1 September 2020 (UTC)

I'm not interested in getting into personal insults with you, so let's not go down that path. GoodDay (talk) 16:13, 1 September 2020 (UTC)

RfC: Alexa Rankings in Infoboxes

What should be done with Alexa rankings in infoboxes? -- GreenC 17:19, 18 September 2020 (UTC)

This is a follow-up to the well-attended discussion here about a year ago about what to do about Alexa Rankings in infoboxes. For example WebCite contains |alexa= 107,988 (December 2018)

Summary of problems:

1. The Alexa numbers change monthly and quickly becomes misleading when outdated.
2. The ranking data is proprietary (Amazon) and there is a tiered fee to access it via API, with the free tier limited to 1,000 queries a month. There are about 5,000 instances of {{infobox website}} that contain |alexa=.
3. It can be web scraped.. but when done on a regular basis and loaded into Wikipedia it would almost certainly violate copyright or a terms of use rule, if not cause an outright IP block.
4. The data can be manually checked and added to Wikipedia.. but in practice done sporadically see the WebCite example (2 years old as of this post), I have seen some over 5 years out of date.

The RfC proposes three options:

1. Keep Alexa rankings in infoboxes as is currently done.
2. Remove Alexa rankings from infoboxes entirely.
3. Automate a solution that has no recurring article edits. Possibilities include:
   • Pull data from Alexa to local hosting (Commons tabular data, Wikidata, etc.) using the Amazon API at the rate of 1,000 per month. This would then display in the infobox via Lua. For example it could look like:

     |alexa={{alexa|webcite.com}}

   • Create a new template {{webrank}} that displays static generic link(s). For example the Wikipedia infobox currently:

     |alexa= 13 (Global, August 2020)

     Would instead appear as: |webrank=Alexa, SimilarWeb

Automated solutions could be mixed ie. the top 1000 are done via API and the remainder via static links .. or some other idea. #3 is a single option for RfC purposes.

Please !vote your preference in order eg. "1 or 2 or 3 in that order" or however you want to word it.

Due to length of time previous participants pinged: @Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists: -- GreenC 17:19, 18 September 2020 (UTC)

Survey (Alexa Rankings in Infoboxes)

• As in previous discussions, it should be removed. So I guess that's a bold 2. --Izno (talk) 18:42, 18 September 2020 (UTC)
• Option 2 These rankings seem to hit more than one item in WP:NOT including WP:NOTDIRECTORY and WP:INDISCRIMINATE. What do the rankings even tell a reader - that some people at some point in time used Alexa for something. IMO they are of no more critical or scholarly value than IMDb ratings. Also why is preference being given to Alexa over other things like Siri? Didn't Ray Bradbury write a short story about one of these automated services taking over the children of an entire town or country. If he was still alive I guessing he would pen one now. MarnetteD|Talk 18:59, 18 September 2020 (UTC)
• Option 2 The rankings are uncylopedic, as they change alot. Also: Arsonxists (talk) 19:30, 18 September 2020 (UTC)
• https://www.realskeptic.com/2013/08/12/why-you-shouldnt-use-alexa-traffic-statistics/
• Keep some sort of traffic metric. I'm new to this question, but at a basic level, the amount of traffic that a website receives is important encyclopedic information that is appropriate for an infobox. We can discuss whether that ought to be in the form of a ranking or in the form of monthly pageviews (is that available for most sites? it seems potentially more useful, especially for lower-ranked sites, since no one knows what 20,000th-most visited website actually means in practical terms), and if we keep a ranking, whether it ought to be from Alexa or somewhere else. But until we have some better alternative, I can't support just removing it. If option 3 with local hosting turns out to be feasible, that would seem the best. We're in 2020; we shouldn't be requiring editor work to update something that could be automated. {{u|Sdkb}} ^talk 19:49, 18 September 2020 (UTC)
• Option 2 - They're not even accurate. O3000 (talk) 20:41, 18 September 2020 (UTC)
• Option 2 They are unencyclopedic. Doesn't matter if we could convince Jeff Bezos to give it to us. We could also automate a feed into {{infobox company}} that pulled in the closing stock price of every public company. But is that what an encyclopedia exists for? No. Infoboxes are for data that is static (or near-static, like a website's owner); data that changes continuously does not belong in the encyclopedia. Much better to use a reliable, secondary source in the article text if a site's traffic is notable, e.g. "As of 2020, Wikipedia.org is one of the most heavily trafficked second-level domains on the internet" (with a reliable source in a ref tag). UnitedStatesian (talk) 20:50, 18 September 2020 (UTC)
• Option 2 - The rankings are unencyclopedic, proprietary, inaccurate, constantly changing and a complete waste of time and effort. If a website is popular, or has been popular, we should explain that in the prose in the context of the website's history, not try to reflect the latest internet fads and trends in our infoboxes, without regard to the importance of history and longevity. Kaldari (talk) 20:52, 18 September 2020 (UTC)
• Option 2 unstable and inconsistent.--Moxy 🍁 22:06, 18 September 2020 (UTC)
• Option 2. It probably meant something way back when, but now? Not so much. Guy (help! - typo?) 22:07, 18 September 2020 (UTC)
• Option 2. Anecdotally, I am yet to see an Alexa ranking that actually provided some useful information or was covered reliable sources. The problem is that it's an arbitrary number produced by an unclear algorithm that isn't basing it on something immediatelly tangible (like MetaCritic, for example). And reliable sources do not care to discuss this ranking, nor follow it on regular basis. Infoboxes are already a big dump of all the stats about a topic that don't have sourcing half the time. You'd think that an "Internet score" a website receives would be a big deal, but that's not how reliable sources treat this one. —  HELLKNOWZ   ▎TALK 22:36, 18 September 2020 (UTC)
• Yup, Option 2, per almost all above, especially the several pointing out the non-encyclopaedic-ness; happy days, Lindsay^Hello 23:16, 18 September 2020 (UTC)
• Option 2 Unencyclopaedic and partisan faux rankings. Fiddle Faddle 23:39, 18 September 2020 (UTC)
• Option 3 is the middle road. It recognizes the issues and addresses them - no watchlist churn, fully automated, no manual work required, data is kept up to date monthly for some fraction of the sites, and the rest static links (no ranking data displayed). As for accuracy of Alexa data this is address in the Alex wikipedia article and by JC in the previous discussion. As for unencylopedia, Wikipedia ranks many things, including itself on occasion. All 5,000 sites could be updated monthly with a cheap $25/year WMFoundation grant once the system is working down the road if there was community support for it. -- GreenC 00:54, 19 September 2020 (UTC)
• Option 2. , but keep them as some sort of periodic table somewhere in the article. They're unstable, and confuse notability with popularity, but popularity is not irrelevant information. But putting the current value in thee infobox is overemphasis. DGG ( talk ) 01:14, 19 September 2020 (UTC)
• Option 2:

• The Tale of Website Popularity Rankings: An Extensive Analysis
• Manipulating Alexa Traffic Rankings
• Why You Shouldn’t Use Alexa Traffic Statistics
• Alexa is Bullshit – Please Stop Using it as a Traffic Comparison Tool
• The Real Problem With Alexa
• How Accurate Are Website Traffic Estimators?
• Why can’t marketers see that digital metrics are bullshit?
• Web Stats for musicians: Lies, Damned Lies and Google Analytics.
• Alexa Rank: Everything You Need To Know
• 2 Creative Ways To Manipulate Your Alexa Ranking

...or just do a google search on "Buy Alexa Traffic".

If anyone with a credit card can inflate a statistic, the statistic is useless as a Wikipedia source. I'm just saying. --Guy Macon (talk) 13:02, 19 September 2020 (UTC)

• Option 2 We are not shills for corporate America (or shouldn't be). GenQuest ^{"Talk to Me"} 13:10, 19 September 2020 (UTC)
• Option 2 - they aren't a statement of fact about the subject since they can so easily be manipulated. They certainly do not belong in an Infobox. They can be misused for promoting a subject. Doug Weller talk 18:28, 21 September 2020 (UTC)
• Option 2 - Alexa ranking is utterly worthless, there's no point in including it. We ought to be able to automatically show a set of information about the domain held in the url parameter, I could just about live with that including Alexa rank (if Amazon provided it for free), but we shouldn't go out of our wayy to include such nonsense. Chuntuk (talk) 11:22, 28 September 2020 (UTC)
• Option 2 Not sure what values these numbers provide, and have concerns about how accurate and maintainable they are. PaleAqua (talk) 18:52, 5 October 2020 (UTC)
• Option 2 I didn't even know what an Alexa ranking was (is?) until I read this RFC. Seems irrelevant. Wes sideman (talk) 21:22, 5 October 2020 (UTC)
• Option 2 Do you have the Alexa toolbar installed? ... You don't? Neither do I. Oh well, Alexa does not count our web surfing in its stats. See selection bias. P.S. If you're on the fence, please read several of the articles Guy Macon posted for in-depth analysis. Mark D Worthen PsyD (talk) [he/his/him] 22:56, 5 October 2020 (UTC)
• Option 2 I don't think this information belongs in the infobox. Another annoying issue is that the red triangle/green triangle is extremely confusing; I can't figure out whether it means the rank is going up (meaning it is getting less popular) or the popularity is going up (meaning the opposite). It might make sense to include the information for the most popular websites (top 100 or so), which have much more stable positions in the ranking. But still I think that info better belongs in the article body, e.g. "According to Alexa Internet, google.com is the most visited website since 2010" or whatever. Sincerely, Ovinus (talk) 07:42, 6 October 2020 (UTC)

Discussion (Alexa Rankings in Infoboxes)

My main problem with alexa is "What are we putting into it, and what are we getting out of it?" If we put in a bot, request data from Alexa, or just do it manually, it doesn't really matter if we are putting in more than what we get out of it. So, what are we getting out of Alexa? Do people really come to Wikipedia to know about the Alexa rank? Arsonxists (talk) 17:44, 18 September 2020 (UTC)

• Have we reached out to Amazon? I'm a firm believer in giving tech giants the opportunity to do the right thing, so that we can hate on them with a clear conscience when they don't. But once in a while they surprise—is there some chance Amazon might be willing to provide us with an account that's not rate-limited so that we could update all the websites monthly? {{u|Sdkb}} ^talk 19:52, 18 September 2020 (UTC)
  • I doubt that, because Amazon would rather get money then trying to help a minor detail in an Infobox. Maybe if it was crucial to us, maybe we could convince them. But not like this. Arsonxists (talk) 20:00, 18 September 2020 (UTC)

    I imagine Amazon would like to help cement the position of a link to Alexa on every article on a popular website... But this is just an aside from the question of whether or not this information ought to be placed in infoboxes. isaacl (talk) 20:14, 18 September 2020 (UTC)

    • Pretty sure they would get the cemented position, and the money. Having Alexa ranks on here is still a win for Amazon. So they would probably refuse the free account, because why not get the money AND the advertisement? Arsonxists (talk) 20:31, 18 September 2020 (UTC)

      Because the money from one account is nothing to Amazon's revenue, while page rank is gold. And based on this discussion at present, it's far from clear that it's "pretty sure" the ranking information will remain. isaacl (talk) 22:03, 18 September 2020 (UTC)

• @Sdkb: How is this info encyclopedic? A ranking that changes frequently isn't encyclopedic. Arsonxists (talk) 19:56, 18 September 2020 (UTC)

  @Arsonxists: the thing I said was encyclopedic was a numeric measure of a website's popularity, but an Alexa ranking is one such measure. I don't think the fact that it changes makes it less encyclopedic; it's no different than listing population counts or U.S. News college rankings (both of which we do). {{u|Sdkb}} ^talk 20:04, 18 September 2020 (UTC)

  @Sdkb: The thing is, things like U.S College elections votes stop changing after a certain amount of time, and U.S population estimates are just an estimate, but Alexa rankings never stop and are NOT an estimate. The ranks change every single day, meaning that it changes too much to be in. encyclopedia. Arsonxists (talk) 20:13, 18 September 2020 (UTC)

• Increase/decrease icons tangent: In the previous discussion, I see that there was some question as to whether the green/red increase/decrease icons were inappropriate WP:Recentism. Personally, I don't see that as a dealbreaker, but I do think it's bad that the icons don't say what time period is being used for comparison. There's also some potential for better use of templates/automation due to the recent creation of {{fluc}}. {{u|Sdkb}} ^talk 20:01, 18 September 2020 (UTC)
• @GreenC: Two things: one, this edit will not have notified anybody (not even Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists) because you didn't sign it; two, what is your brief and neutral statement? At over 2,600 bytes, the statement above (from the {{rfc}} tag to the timestamp that I added for you) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Media, the arts, and architecture. The RfC may also not be publicised through WP:FRS until a shorter statement is provided. --Redrose64 🌹 (talk) 20:33, 18 September 2020 (UTC)

Thanks! -- GreenC 21:50, 18 September 2020 (UTC)

• Is this something we could work with WikiData on and/or get a WMF grant? WikiData would probably love to host this kind of data and it could populate the infobox from there. A WMF grant could fund the fees for whatever the next tier is so we can make the ~5k requests a month that we need to update these. — Wug·a·po·des​ 23:35, 18 September 2020 (UTC)
  • Looking at the fee structure GreenC linked, even if we wind up with 10k requests a month it winds up being like $5. — Wug·a·po·des​ 23:37, 18 September 2020 (UTC)

Yeah it's cheap, $25 a year for current needs. Without institutional support there is no guarantee payments could be maintained in perpetuity. Regardless of the outcome here, it might still be hosted at Wikidata or Wikicommons, and used for other language wikis. -- GreenC 00:43, 19 September 2020 (UTC)

@I JethroBT (WMF): Could you help us navigate this? A $500 grant could keep this going for 20 years which is a bit longer than the 12 month max for Rapid Grants, so I don't think we'd qualify for any of the grants. Should we be looking at WMF programs other than grants? — Wug·a·po·des​ 01:16, 19 September 2020 (UTC)

@Wugapodes: I don't have all the details around this proposal, but in general, it's not an issue to request $500 for a Rapid Grant and simply report on outcomes/data after the first year. That some of the funded work will continue beyond 12 months is not problematic, and in fact, is basically ideal. If the benefits of this program/service are going to persist after the first year, it is clearly worth funding in my view. I JethroBT (WMF) (talk) 20:00, 1 October 2020 (UTC)

Annual visitors parameter?

Okay, so it seems that, unless something changes, the Alexa parameter is on its way out. But I maintain that it is useful to have some sort of metric that indicates the popularity of a website. Would the community support having an |annual visitors= (or |annual pageviews=) parameter? It really doesn't seem all that different than having an annual visitors parameter for {{Infobox museum}}. {{u|Sdkb}} ^talk 00:47, 21 September 2020 (UTC)

Do you have a source for that data in mind that is likely to be both free of cost and freely licensed? --Izno (talk) 02:33, 21 September 2020 (UTC)

@Izno: I don't think there's any entity that collects that data at scale, so it'd come from individual websites. E.g. for Wikipedia, we'd cite as 882 million Many websites don't release their numbers, but I think it'd be better to include it for the ones that do than to have nothing at all. {{u|Sdkb}} ^talk 04:21, 21 September 2020 (UTC)

Even for Wikipedia, the stats aren't clear. The figure of 882 million is a monthly rather than yearly figure and represents unique devices rather than visitors. Considering that people browse the internet on phones, PCs, laptops, games consoles, equating unique devices to visitors isn't straightforward. Richard Nevell (talk) 10:02, 21 September 2020 (UTC)

References

But then we're facing WP:V and WP:RS issues. The only people who (possibly) know how many visitors they get are the sites themselves. (And: pageviews I'd believe before visitors.) Such an infobox param supposes we have somebody to trust for their values. — JohnFromPinckney (talk) 09:41, 21 September 2020 (UTC)

Actually, it is not true that "the only people who (possibly) know how many visitors they get are the sites themselves." It is impossible for the site to know how many visitors they get. The reason is caching. Let's say you have a really great website that is hosted in New Zealand. A thousand people using the same ISP in New York City all visit at around the same time. Now the ISP could send a thousand requests to New Zealand, or they could just send one request, store the result locally, and serve that to the other 999 users. Cheaper for the ISP, the users get the page faster, but the site in New Zealand don't know how many visitors they have.

The sites have a bunch of tricks that try to defeat caching and force each visitor to go to New Zealand, but the local ISPs, browser makers, adblockers, tracker blockers, and pretty much every computer between NZ and NYC work to defeat those tricks. I won't bore you with the details, but the end result is that the stats are all educated guesses. --Guy Macon (talk) 16:19, 29 September 2020 (UTC)

Aren't all statistics educated guesses? Annual visitors to a museum, or passengers using a train station is only ever going to be an educated guess. That seems a reason to good avoid excessive precision, but I think the figure is still valuable. --Paul Carpenter (talk) 13:55, 30 September 2020 (UTC)

Log out second chance

Tracked in Phabricator
Task T217914

Isn't it about time Wikipedia had a "safety valve" on the "Log out" icon? I have accidentally logged out many times because I clicked the icon by mistake, and then I had to log in all over again. It should be a simple matter to modify the software so when an editor clicks the icon, a message appears, asking, "Are you sure you want to log out? Yes, No."—Anita5192 (talk) 18:16, 27 September 2020 (UTC)

Agree . {{u|Sdkb}} ^talk 18:24, 27 September 2020 (UTC)

Only to succumb to the documented "unconscious me always press Yes so I'll press Yes this time oh oops conscious me didn't mean to press Yes". Yeah, no. --Izno (talk) 18:33, 27 September 2020 (UTC)

@Izno: That has never happened to me. I think it is very common for a visitor to any web-site to make the first mistake, but extremely uncommon to make the second mistake. When I accidentally click "Log out," I mean to click something else, and I don't automatically click "Yes."—Anita5192 (talk) 19:34, 27 September 2020 (UTC)

I am glad you are so conscientious (see also anecdotal evidence). Most people are not. That said, there is discussion at phab:T217914 about the issue on mobile. --Izno (talk) 20:17, 27 September 2020 (UTC)

phab:T217914 has a discussion on this. A personal user script (see FlightTime's User:FlightTime/confirm-logout.js) can be used to add this for your own account if you want. — xaosflux ^Talk 20:20, 27 September 2020 (UTC)

I edit Wikipedia from my laptop computer only, using Google Chrome. I noticed on the phab:T217914 page that someone wrote, "It's not a mobile-only problem; I've clicked log out accidentally on desktop using a mouse." However, I did not see a response to that post on the page. I loaded the JavaScript code at User:FlightTime/confirm-logout.js into my common.js page and bypassed my cache, but it doesn't seem to do anything.—Anita5192 (talk) 21:59, 28 September 2020 (UTC)

Agree in a lightweight way if possible. That is, not changing MediaWiki itself but building it into a skin, user preferences or Javascript. I have often hit the logout accidentally at the top of the screen, and many times in the middle of teaching Wikipedia editing in front of dozens of people. As the Phabricator discussion mentioned, it is currently the only "destructive" action in that bar of links, so having a safety net to warn about logging out would be consistent with the user interface. -- Fuzheado | Talk 14:30, 29 September 2020 (UTC)

Agree, I've done it often enough to comment here, a few times a year. For me it occurs when I want to check my contributions for something and the uploaded page has a slight hesitation and then slides left as I click. The second-chance would save some of the time involved to log back in. Randy Kryn (talk) 14:38, 29 September 2020 (UTC)

I have also done it when I meant either to check my contributions or to click one of the Chrome icons.—Anita5192 (talk) 15:57, 29 September 2020 (UTC)

Agree and please do this. Otherwise it sucks. ❯❯❯   S A H A 11:00, 1 October 2020 (UTC)

Agree not a feature I'm personally looking for, but seems to be useful. However, if the logout button is ever removed as a stand-alone button and placed inside a menu,(like gmail for example) a further confirmation would be unnecessary. In other words, the actions necessary to logout should be two-clicks at most. $\langle$ Forbes₇₂ | Talk $\rangle$ 17:56, 1 October 2020 (UTC)

• There might be a preference but it is likely that the default would remain as it is now to avoid the problem of a hasty exit from a shared computer. A typical scenario is that someone logs in at a university or similar public place. Later, they notice they are half an hour late, and click "log out" while running away. They never see the "are you sure?" and they stay logged in. Johnuniq (talk) 00:40, 2 October 2020 (UTC)

Agree I like Fuzheado's idea of having it in user preferences. Personally, it discourages 2FA a bit because it takes a while to log in (might have to find the phone too, which can be a challenge). Ovinus (talk) 07:44, 6 October 2020 (UTC)

Proposals for ending the Infobox wars

Infobox wars
WP:ALLROADSLEADTOINFOBOXES
Date 2013–present Location English Wikipedia Status Possibly petered out due to exhaustion
Belligerents
radical infobox inclusionists	radical infobox exclusionists
Casualties and losses
bystanders' sanity

The infobox wars have now been raging for longer than the duration of World War II. Despite 2 ArbCom cases and ArbCom's request for community discussions, nothing's really changed since the opening salvos were fired back in 2013. Personally, I'm tired of seeing the same people show up en masse to talk page after talk page to debate over and over and over again whether or not an infobox should be in an article, especially since all such discussions quickly degenerate into back and forth name-calling. To take just one example, Mary Shelley has had 4 infobox proposals in the past 3 years. With this in mind, here are some ideas for ending (or at least reducing) the infobox wars. Feel free to add more ideas.

• Proposal A - No one may propose adding or removing an infobox to an article if there has already been such a discussion within the past 2 years.
• Proposal B - No one may propose adding or removing an infobox to an article unless they are one of the top 10 contributors to that article (as judged by the Xtools authorship tool).

-- Kaldari (talk) 00:00, 29 September 2020 (UTC)

• User:RexxS/Infobox_factors is good reading. --Izno (talk) 00:09, 29 September 2020 (UTC)
• Radical idea and one I know will be met with contention, but another idea would be an RFC to discuss whether all articles where it is feasible that an infobox should be present, though editors are not required to use all fields present even if there is data to fill those fields (knowing for example the concerns those at Kubrick have of that). 95% of the issue of infoboxes are people coming here expecting to find "structured" data that 99% of all other articles have. I know the past discussions in this, including ArbCom have been to leave this to a page-by-page consensus, but that is clearly not working, and things have changed since (the introduction of Wikidata, Google/Bing's presentation of search results, etc.). Again, this would be an RFC to discuss this possibility, which I know certain editors will refuse adamantly, but this is a consensus thing. --Masem (t) 00:22, 29 September 2020 (UTC)
  • Is there a WP:RS for any of those numbers. Having been through over 110,000 of the 'pedia's articles in my own editing I can guarantee that the number that have infoboxes is nowhere near 99%. It is also interesting how everyone talks about what readers expect to see without ever having performed a scientific survey to validate their statements. MarnetteD|Talk 00:35, 29 September 2020 (UTC)
    • I should add there are types of articles that we have no canned infobox for that we can make the topic conform into, and so in such cases, this would be reasonable where an infobox could be omitted. These are usually for more abstract terms that lack any type of hierarchical data. (This is what I meant by "where it is feasible".
      And as a rough test, I used Category:American women by occupation with Petscan, adding in a number of known infoboxes common for this group. Of the 9790 entries, I got to about 3000 pages without the most common infoboxes, and spotchecking those (to find any other infoboxes) the ones that were missing it were all observed to be stub, not well developed articles. Nothing of the type like Kubrick or other pages that have been fully developed and where consensus presently has been to leave an infobox out. This is far from scientific, but I would definitely say that for well-developed (non-stub, non-start articles), the number that lack infoboxes is far fewer then 5% based on this very unscientific study. --Masem (t) 01:32, 29 September 2020 (UTC)
  • I think that is about right. I am not sure the restrictions above are the path forward. More we need a discussion on making them standard and if so in what capacity. PackMecEng (talk) 00:37, 29 September 2020 (UTC)
• Both A and B are awful proposals and completely biased in their presentation. --Gonnym (talk) 00:56, 29 September 2020 (UTC)
  • You're going to have to explain what you could possibly mean. Both proposals look to be completely neutral - they take absolutely no inherent side in disputes other than stability - and while you can certainly disagree with them on any number of grounds, e.g. proposal B is unacceptably inimical to WP:OWN (my opinion), your comment neither adds to collective understanding nor actually advocates for your position in a meaningful way. VanIsaac_WS^cont 01:11, 29 September 2020 (UTC)
• If it came up at an RfC I would support proposal A. For no other reason it streamlines what has become a sort of drag on the community. -- GreenC 01:54, 29 September 2020 (UTC)

To add.. Option A is recommended, but it does not "solve" this problem because like water erosion there is no solution rather you redirect, slow down and so on. "A" is a way to reduce the disruption, which is the main issue, the particulars about infoboxes is almost a side issue to the larger problem of disruption. -- GreenC 05:35, 30 September 2020 (UTC)

• I have never encountered a contentious infobox discussion. If the problem is a cabal of editors going from page to page starting infobox discussions, we should just topic ban those editors. If that is not possible, we should develop project-wide guidance similar to Masem's suggestion. — Wug·a·po·des​ 01:57, 29 September 2020 (UTC)

  Have a quick look at Talk:Frank Sinatra. The argument goes back forever and has been re-launched zillions of times. — GhostInTheMachine ^{talk to me} 08:38, 29 September 2020 (UTC)

• Proposal B codifies article ownership into policy and should be a nonstarter. – Teratix ₵ 06:50, 29 September 2020 (UTC)
• I've added {{Infobox war}} to this discussion since it seems apropos. Please feel free to fill in more parameters. EEng 09:39, 29 September 2020 (UTC)
• Mleh- I am indifferent to infoboxes, except when they're used to try and make substub non-articles look deceptively like articles. I oppose both options: the first one strikes me as "Thou shalt not talk. Thou shalt not think" and the second one amounts to assigning ownership of articles to prominent editors. Reyk _YO! 10:25, 29 September 2020 (UTC)
• Argh, is this still going on? Good grief. Personally I have never encountered a contentious infobox discussion in my own editing, but maybe I have just been lucky. I may be wrong, but my impression right now is that these "infobox wars" are limited to a small number of highly opinionated editors arguing over and over between themselves on a relatively small number of articles. If that is the case, then a better solution would be to issue a bunch of community topic bans to them for 2-3 years and then have some peace. If the problem goes deeper, then something like what Masem suggest makes sense to me. An RfC proposal to formalize the existence and structure of infoboxes along the lines that Masem mentioned seems likely to me to gain broad consensus. On the other hand, proposals A and B suggested above seem both extreme an unnecessary. Nsk92 (talk) 10:45, 29 September 2020 (UTC)
  • This is pretty much my read of the situation: there's probably a few dozen, very senior editors that have been very vocal on not wanting infoboxes on certain articles for multiple reasons. Most of us experienced editors know not to touch that. Newer editors - who see nearly every other developed page with infoboxes and have no knowledge of the infobox ARBCOM cases or the like - add infoboxes or ask valid questions of why no infoboxes, and that will never be a cycle that we can get out of beause there will always be new editors. So either we're going to have these going on forever (and as others point out, the two suggested RFC questions don't solve this), or we actually readdress the consensus around infoboxes, because if we're catering to a few dozen editors when hundreds more want it a different way (if that is what consensus is), then there's a problem. But best I can recall we have not had an RFC on how mandatory or optional infoboxes are for at least 5 years so I don't know that read: I know they're expected, but that's different. --Masem (t) 14:09, 29 September 2020 (UTC)
• I would reject both. B has problems, but it's also a strength of Wikipedia, and this kind of 'ownership' seems incompatible with the purpose. A does not exactly fix the issue -- the Sinatra RfC was brewing for 2 years. Masem's proposal probably doesn't help either - infoboxes are, indeed, not required on all articles. Particularly it'd look silly on short ones, and it's likely to annoy some editors who focus on their writing and don't like IBs. Further, their values are likely to get bloated so there will still be arguments on what labels to keep/remove. It's a difficult problem to solve from a central level, if pushing down a single rule, seemingly. I think what is more likely to be effective is prescribing actual guidelines which will help determine whether an infobox should be on an article (an expansion of MOS:INFOBOXUSE).
  One route to a solution is just making the infoboxes more palatable. Maybe modifications to infoboxes will help, too. People are opposed to too many fields, so maybe trimmed down 'wrappers' of contentious infoboxes with only support for some fields will be a sustainable middleground. Kaldari maybe WMF design input could be helpful? mw:Streamlined Infoboxes seems interesting. ProcrastinatingReader (talk) 18:14, 1 October 2020 (UTC)
• I would reject both, B just seems both against our ethos to an unacceptable level but also a potential source of its own aggravations and gaming. Articles can change a simply staggering amount in 2 years, so don't think that's wise. But perhaps some process to enable more targeted 1 year moratoria at specific troublesome pages. Nosebagbear (talk) 13:28, 29 September 2020 (UTC)

  The moratoria can already be applied to specific troublesome pages under the existing Infobox DS. I don’t think it’s working. We need a broad solution to the issue. And the issue is targeting behaviour and conduct on individual pages doesn’t work when the underlying issue is a fundamental content dispute. The issue can only be resolved by addressing the content issue.

  In usual cases, a clear MOS guideline etc would be sufficient clarification to put the matter to rest if it’s just individuals acting out (or just enact topic bans), but since the community is unable to agree on a standard I don’t think the conduct (which is a symptom) is the root of the issue here. Thus sanctions and topic bans likely not the appropriate way to address legitimate content concerns, however expressed. Banning the vocal opponents may dim the issue, but doesn’t seem to be the correct way to proceed. If their concerns were without merit, the community would have no objection passing an update to guidelines to say so. ProcrastinatingReader (talk) 14:18, 29 September 2020 (UTC)

• Can someone link to one of these specific contentious infobox discussions, preferably a recent one? Like many other people here have commented, I've never seen one ever, contentious or otherwise, other than meta-discussions like this one about how bad the problem is and what to do about it. Ivanvector (^Talk/_Edits) 14:20, 29 September 2020 (UTC)
  • Check the Cary Grant talk page, aye, where many a dusty hill has been held under heavy fire (someone should write an epic poem). Randy Kryn (talk) 14:41, 29 September 2020 (UTC)
  • The Arbcom case over this is here Wikipedia:Arbitration/Requests/Case/Civility in infobox discussions. Other pages I know that have been a hot bed have included Talk:Stanley Kubrick and Talk:Frank Sinatra but you likely need to look through archives of those to find the discussions. --Masem (t) 14:53, 29 September 2020 (UTC)
• Two editors heavily involved in this dispute (Cassianto and SchroCat)—they're the primary participants in all the discussions cited here so far—have recently left the project. Maybe we should wait to see if that changes things before considering a fresh round of sanctions? – Joe (talk) 15:06, 29 September 2020 (UTC)
• It's my sense that this imbroglio is largely in some biography article areas, so maybe start whatever proposed new "rule" there is with biographies, and see how that goes. (In that biography realm, it is something to observe, because that debate (or war) in effect regularly centers around not whether there will be something in a box in the top right corner, but whether it will be limited to a picture-box, or contain more). -- Alanscottwalker (talk) 16:48, 29 September 2020 (UTC)
  • There is a idea I've had for some specific types of bios - mostly creative people with a widely varied career - that most of the typical {{infobox person}} or its variants just don't work well and thus can be argued that an infobox doesn't help that much or if used will draw people to add the "missing" information that was purposely omitted because it can't easily be summarized in an infobox (Kubrick's fits this idea well). But at the same time, there is basic structured data like birth date + date, death place + date, broad profession list, and notable spouses and the like that can still be documented in an infobox that is the type of information that I see being asked for by the new editors that are the ones asking for infoboxes. This would need to be a discussion under my suggested RFC about the nature of infoboxes altogether. --Masem (t) 17:29, 29 September 2020 (UTC)
• Oppose B for WP:OWN per User:Teratix and others. RudolfRed (talk) 17:32, 29 September 2020 (UTC)
• Oppose both. Just add an infobox to every article (preferably from Wikidata), job done. Thanks. Mike Peel (talk) 17:47, 29 September 2020 (UTC)

Seeing as this seems to be cropping up as a bone of contention in biographies, where I'm sure much of the heat comes from the question of the choice of infobox, I would suggest that at the very least the generic {{Infobox person}} should be a default whenever you have an article about a non-fictional person. I edit in too many esoteric parts of Wikipedia to be able to say that every article has an appropriate infobox available, e.g. Perkins Brailler. VanIsaac_WS^cont 07:38, 30 September 2020 (UTC)

If the Perkins Brailer absolutely needed an infobox then I think {{Infobox keyboard}} could be made to fit: since it only has four uses already, I'm sure it could be adapted somewhat. But you're right, adding an infobox to every article does pose a challenge when it's not immediately obvious what type of thing a thing is. I would suggest that some things (persons, buildings, countries, songs, books, animals) can't really get away without having them but applying to every article ever, especially newer ones, would be too much. --Paul Carpenter (talk) 13:34, 30 September 2020 (UTC)

• I don't see why option B is perceived to go against WP:OWN. The question of whether to have an infobox in a particular article has little relevance to the function and encyclopedicity of that article, and Wikipedia's core policies have no bearing either. It's largely a stylistic choice, and for stylistic choices it is only common sense – in infoboxes or elsewhere – to accord greater weight to the preferences of the people who have put in the most work. A somewhat similar principle operates in MOS:RETAIN, which guides the choice of British or American spelling. – Uanfala (talk) 14:54, 30 September 2020 (UTC)

WP:RETAIN is absolutely nothing like option B above. It simply identifies a default consensus for an English variant based on the history of a page. It privileges absolutely no editors, and that default consensus is only used as a stability policy in the absence of an established consensus. Option B, on the other hand, privileges certain editors, allowing their opinion to veto consensus. It is not a stability policy, as those privileged editors can impose a decision no matter how entrenched another choice might have been. Option B is the epitome of WP:OWN, where certain editors are elevated as the masters of a page in regard to infoboxes, no matter the consensus or stability. VanIsaac_WS^cont 21:55, 30 September 2020 (UTC)

I agree with Vanisaac. Proposal B is a pure form of WP:OWN. Completely unacceptable and goes against the fundamental editing principles of Wikipedia. The proposal offers a cure that is a hundred times worse that the desease. Not only would it create a group of privileged editors for each article with veto powers over certain decisions, it would also encourage gaming and trickery in running the edit count in order the become one of those top 10 editors. Really, it would have been hard to concieve of a worse idea than Proposal B. Nsk92 (talk) 22:31, 30 September 2020 (UTC)

• Oppose both, especially oppose B for all the reasons above and zero good reasons in favor. Natureium (talk) 01:50, 2 October 2020 (UTC)
• Oppose both If a specific infobox, or lack thereof, proves to be a constant issue, a moratorium on bringing it up on the talk page can be agreed to on that talk page. This should really be decided by local consensus. ~ HAL333([1]) 03:50, 5 October 2020 (UTC)
• Oppose Both "B" per WP:OWN. For "A" 2 years is too long. PaleAqua (talk) 18:54, 5 October 2020 (UTC)

Proposal: Give editors a chance to back out before adding broken {{DISPLAYTITLE}}

New, naive editors account for over half of recent incorrect uses of the {{DISPLAYTITLE}} magic word on article pages. This wastes other editor's time as we have to clean up after them.

I propose that editors be warned and given a chance to back out before making an edit that will put the page into Category:Pages with disallowed DISPLAYTITLE modifications.

This would likely require an edit filter which has a non-zero cost to each and every edit, which is why I'm proposing it here first. davidwr/(talk)/(contribs) 18:13, 29 September 2020 (UTC)

@Davidwr: From a quick glance, it seems a large amount of pages in that category are for User pages. Perhaps a first step would to be to disallow the template in User space, and then tackle the rest of the problem. RudolfRed (talk) 18:32, 29 September 2020 (UTC)

I'd be happy for a bot to run through User/ User talk and remove them all. FWIW, 425 are in "Draft:" space. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:30, 29 September 2020 (UTC)

Actually, I'm not too concerned about incorrect use in user: and Draft: space, but it wouldn't hurt to warn users adding new user- and draft-pages to that category. I'm more concerned about mainspace. If you have a bot though, perhaps the easiest thing to do is run the bot against mainspace pages in that category once or twice an hour. I would give a 15 minute grace period in case someone made the change in anticipation of a page move or someone reverting their own mistake. davidwr/(talk)/(contribs) 20:15, 29 September 2020 (UTC)

How many occurences of this are there in article space? I'm afraid that I'm not prepared to wade through a category whose first few pages show the vast majority in user space and most of the rest in draft space. If it's over half being by new, naïve editors then it doesn't matter: it's the absolute number that is important. Phil Bridger (talk) 20:30, 29 September 2020 (UTC)

As of a minute ago, none, but you can check the real-time list[2] any time. There is a link to it, and for a version of it in all namespaces, on the category description page. Note - the non-"recent" lists may be missing items, I'm not sure why.

The reason there are so few is I have the category on my watchlist and I and others play whack-a-mole when someone moves an article page into that category, which is several times a day minimum. That "whack a mole" is the "wastes other editor's time" that I mentioned in the opening comment. davidwr/(talk)/(contribs) 21:51, 29 September 2020 (UTC)

@Davidwr and Phil Bridger: If we wanted to make the category easier to wrangle, we can edit MediaWiki:Restricted-displaytitle-ignored to put pages in different namespaces into different categories. I just set this up on testwiki:MediaWiki:Restricted-displaytitle-ignored, so there, articles now go into testwiki:Category:Articles with ignored display titles, and everything else goes into testwiki:Category:Pages with ignored display titles. Perhaps we could do something like that here too. Jackmcbarn (talk) 06:39, 30 September 2020 (UTC)

And surprise surprise, the first five userspace ones I checked on were all from using the hand visual editor checkbox for displaytitle, which has a tooltip that already reads You can enter wikicode here to change the style markup of the page title, including the capitalization of the first character. This field cannot be used to change the text of the page title. To change the title of the page, use the move function. Of course, no one reads that. This is compounded by VE developers not using distinct labels there, perhaps some votes at phab:T110329 would help - if these had labels we could remove the section at least from newbies. — xaosflux ^Talk 22:55, 29 September 2020 (UTC)

VE strikes again! EEng 05:41, 30 September 2020 (UTC)

Use internal instead of external link for edit, history, purge and new section links

I think that using Special:EditPage, Special:PageHistory, Special:Purge and Special:NewSection is better than using external links and should be introduced anywhere. (see also this discussion) 217.117.125.72 (talk) 18:17, 29 September 2020 (UTC)

I think this would make an excellent "preferences" option. There are times when I would prefer an external link, but most of the time, I prefer internal one if it is available. davidwr/(talk)/(contribs) 19:49, 29 September 2020 (UTC)

Link's within Wikipedia are internal links, and should certainly be marked as such, to keep the symbolism of the external link icon consist. This seems like it should be non-controversial maintenance. {{u|Sdkb}} ^talk 21:11, 29 September 2020 (UTC)

Support proposed change. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:16, 30 September 2020 (UTC)

Support possible minor performance improvement of using internal links over a full url, doesn't break anything. Not a high priority, but seems to be worth switching the two dozen templates with "improve it" links on Wikipedia:Template index/Cleanup. $\langle$ Forbes₇₂ | Talk $\rangle$ 18:15, 1 October 2020 (UTC)

Addendum - While we're at it, can we please put some description on pages that act to "purge" the cache as to what pressing the button will do? It's not clear to users that this is pretty benign and is only meant to refresh stale cached info. Otherwise, "purge" sounds very violent and destructive. :) Pages where this is relevant include Special:Purge and when "action=purge" is in the URL, like https://en.wikipedia.org/w/index.php?title=Foo&action=purge . Not sure where to file this though. -- Fuzheado | Talk 13:45, 2 October 2020 (UTC)

Huh? It looks to me like both Special:Purge and https://en.wikipedia.org/w/index.php?title=Foo&action=purge already display a notice: "Purging a page clears the cache and forces the most current revision to appear. For pages with random components, it also forces a new random selection." and both also have a link to WP:PURGE labeled "what does this do?". 〈 Forbes₇₂ | Talk 〉 08:05, 3 October 2020 (UTC)

Guild of MoS fixers

Just like we have Wikipedia:WikiProject Guild of Copy Editors, what about having a Wikiproject Guild of MoS Fixers? Editors of under this wikiproject will fix MoS issues in the requested articles. It will work in a similar way like the GOCE. I think it will help new/inexperienced users. I have proposed this from my personal experiences. Multiple times GA failed, put on hold due to mos issues (mainly with citations). ❯❯❯   S A H A 13:53, 30 September 2020 (UTC)

• The problem with MoS is the myriad of rules are often created by a small number of editors, in practice most of us don't follow those guidelines exactly or are aware of the discussions (if there was any). The friction this creates is mostly kept in check because there is no organized effort to impose the entirety of the MoS onto masses of articles, and no MoS Noticeboard that creates a group of like-minded editors able to impose changes. Granted much of the MoS is uncontroversial most of the time like short versus long dash in dates, etc.. The Guild sounds like a reasonable idea but I hope it doesn't devolve into a Hey, Rube!. -- GreenC 16:06, 30 September 2020 (UTC)
• Part of the role of the guild of copy editors is to fix issues of MoS noncompliance in articles, so this sounds redundant. {{u|Sdkb}} ^talk 16:09, 30 September 2020 (UTC)

• Sdkb, I will partly disagree. Issues like citations formatting aren't addressed. ❯❯❯   S A H A 16:29, 30 September 2020 (UTC)
• Agreed. It's a part of what we call "minor copy edit", which also includes things like spelling corrections. Presumably that would fall under the umbrella of the Guild of Copy Editors, given its name, so this seems totally redundant and unnecessary. Re the preceding comment, citations formatting has nothing to do with MoS, to my knowledge, and I think we could do well without a Guild of Citations Formatters (but if we do get one, sign me up!). ―Mandruss ☎ 03:06, 1 October 2020 (UTC)

• No, no, no -- a thousand times no Just the name "Guild of MOS fixers" fills me with unspeakable dread. There's far too much mindless gnoming already. If GOCE (which has a good base of experienced editors) wants to offer a format-refs service or something, fine. EEng 02:50, 1 October 2020 (UTC)

• User:EEng The name is just a sample. It can be changed. Maybe we can have a branch/annex of GOCE... ❯❯❯   S A H A 09:14, 1 October 2020 (UTC)

ArnabSaha, this is a really bad idea. Not that I blame you for it, crappy formatting is an issue, but there have been so many lame edit wars over attempts to enforce MOS, a stylistic preference, over governing content policies like BLP and NPOV, that this is just going to be a huge drama magnet, encouraging MOS-obsessives to feel even more justified in preferring consistently formatted bollocks over ugly-looking fact. Guy (help! - typo?) 09:59, 1 October 2020 (UTC)

I've taken the liberty of making your post MOS-compliant. Hope you don't mind. EEng 10:26, 1 October 2020 (UTC)

• Addition/Edit: Based on the feedback received, I want to edit the proposal. Fixing whole MoS is a big deal. So, what about something more specific? Like fixing the citations. Many times they aren't properly formatted and cause issues during GA/DYK (saying from personal experience). ❯❯❯   S A H A 11:14, 1 October 2020 (UTC)

Adding IMDb, Rotten Tomatoes, and Metacritic to external links (wherever possible)

Before !voting, please review Wikipedia:Village pump (proposals)#Adding IMDb & Rotten Tomatoes ratings to article infobox (wherever possible). Many of the same arguments apply.

Survey: IMDb, Rotten Tomatoes, and Metacritic in external links

Should IMDb, Rotten Tomatoes, Metacritic, or any similar sites be mass-added to the external links section of the Wikipedia pages for the films they review? --Guy Macon (talk) 22:55, 30 September 2020 (UTC)

• No to all.

The result of the previous RfC was:

"Consensus to not use critic review aggregations in the infobox, including but not limited to Rotten Tomatoes and Metacritic. There is consensus that such aggregations are not factual content of the sort suitable for an infobox. Concerns have been raised that any individual aggregator methodology is not appropriate when presented in an infobox without further context."

...and...

"Consensus to not use IMDb in the infobox. No-one but the proposer is in support. Prior to this discussion, there was recent consensus (WP:RSP#IMDb) that IMDb is not reliable for ratings as they are user-generated. There is no consensus here to overturn this decision, or to include such content in the infobox."

In my opinion, the exact same arguments apply in the external links section. I have no opinion about using these as sources in the body, and have purposely not asked that question here. --Guy Macon (talk) 22:55, 30 September 2020 (UTC)

• No to all IDMB should be avoided period. RT and MC are appropriate in reception sections as refs so should not be in the EL section. --Masem (t) 23:07, 30 September 2020 (UTC)
• No to all these websites rarely if ever make a helpful EL, as pointed out above. I would be infavor of mass removal of IMDB links. (t · c) buidhe 23:24, 30 September 2020 (UTC)

• The question is whether they should be "mass-added". In that sense this almost seems like a bot request. There is no question here about whether such links can or should be in the external links section. If the intention is to find consensus along those lines, the question will need to ask that explicitly (and should be both an RfC and posted to CENT, once the question is direct, given the thousands of articles it would affect). On the general topic, I will say that I don't often edit film articles but I am usually glad for these links at the bottom. In fact, I dare say that one of the most common things I use Wikipedia for as a reader is for film articles (often including clicking these links, and sometimes visiting Wikipedia specifically to use its ready array of these links). Obviously they shouldn't be used as sources apart from e.g. the Rotten Tomatoes percentage itself, but EL sections aren't for sources. — Rhododendrites ^talk \\ 23:26, 30 September 2020 (UTC)
  • Sorry for being unclear. I copied the wording from the recent infobox RfC. While I certainly wouldn't want a bot mass adding these sort of links, I wouldn't want a bot mass-removing them either. If an editor decidesd that an external link to IMDB is needed on one or two movies, I am inclined to let it be and assume that they had a good reason. But what I am seeing is editors who are adding a external links to IMDB, Rotten Tomatoes, etc. to every movie. An editor adding external links to thousands of pages by hand is still "mass adding" them. --Guy Macon (talk) 21:11, 1 October 2020 (UTC)
• I'd say no to both Rotten Tomatoes and Metacritic, because they'll most likely already be used as references in the Reception section. However, IMDb is considered both an unreliable source for references and a very useful link for both readers and editors, so I'd say yes to IMDb being added to External links, given that it would never be used for references. Rhododendrites is right in that this discussion should be advertised to as wide an audience as possible. El Millo (talk) 23:52, 30 September 2020 (UTC)
• No mass adding or mass removing. The Rotten Tomatoes and Metacritic links can be removed if they are already in the references but they are in a lot of articles that have no reception section so are useful for editors who wish to use them for expanding the article and also as a quick test of the notability of the film. IMDb is not permitted as a reference but is a useful external link for minor cast listings and so forth, imv Atlantic306 (talk) 00:14, 1 October 2020 (UTC)
  • Mass removing that undoes mass adding is OK, right? If an editor decided that an external link to IMDB is needed on one or two movies, that's one thing. But I am seeing editors who are adding an external link to IMDB to every movie. --Guy Macon (talk) 21:03, 1 October 2020 (UTC)
    • I think if you are going to remove Rotten Tomatoes links from pages without review sections / Rotten Tomatoes citations you should just add them there and then remove them from External Links afterwards. (talk) 08:38, 1 October 2020 (UTC)
• They should generally be present, but not mass added. To put it simply, they're useful to readers: Metacritic and Rotten Tomatoes provide a directory of critic reviews, and IMDB provides non-encyclopedic but useful information like a parents guide. To put it in the context of the external links guideline, Metacritic and Rotten Tomatoes fall under WP:ELYES criterion 3, which includes Sites that contain neutral and accurate material that is relevant to an encyclopedic understanding of the subject and cannot be integrated into the Wikipedia article due to...amount of detail...or other reasons, and IMDB falls under the "links to be considered" criterion 4, Sites that fail to meet criteria for reliable sources yet still contain information about the subject of the article from knowledgeable sources. We aren't talking about deeming them reliable sources here; we need to have some basic trust that our readers are smart enough to know that they're not impeachably fact checked yet still make use of them.

Regarding having them as both a reference and an external link, I reviewed WP:ELDUP, and I don't really see what the problem would be. They can be useful both as a citation for a critic consensus and as an external link for further reading beyond Wikipedia's level of detail; those are separate purposes that can co-exist.

Regarding mass-adding, I don't support that, since there will be exceptions, such as films with no or few reviews, or films where the IMDB page has perhaps been brigaded or corrupted or something. {{u|Sdkb}} ^talk 00:56, 1 October 2020 (UTC)

• No to all. I agree that IMDB and others do generally add 'additional information', but there is certainly not a blanket. I do have the feeling that a lot of IMDB is now being added because it is IMDB and that IMDB is marked as 'generally yes' instead of critical evaluation whether it actually merits addition. IMDB often has more extensive lists, but not always and one can ask sometimes whether that is information that is really an expansion on the material in Wikipedia. It can also overlap with what is available already on the (generally linked) official website of the subject or other, more reliable, websites. Being user generated one can also ask whether they are always correct. Also, a lot of information on IMDB can be incorporated into our articles, it is mainly on the extensive lists that it may be of an addition use. Other reviews are often used as a reference already, or should be used as a reference. WP:ELDUP should generally be followed, but there are exceptions where either IMDB or a review has really much more information.
  But. I strongly disagree with making an ==External links== section a dumping ground for material that 'maybe sometime in the future' can be used to write something in the article: a) then just write it in the article, it takes just a minute more to write '=== Reviews ===<newline>Metacritic evaluated .....<ref>paste metacritic url</ref>' as that it takes to write '* [<paste metacritic url> metacritic review]' in the external links section; b) you can just dump it on the talkpage just as well as in an external links section. Unfortunately, having first reviews there does tend to invite more (sometimes non-notable) reviews to be added.
  These links really need to be added on a case-by-case basis, using the guidance of WP:EL and common sense. --Dirk Beetstra ^{T C} 07:13, 1 October 2020 (UTC)
• No to all (first preference), and certainly No to Metacritic and Rotten Tomatoes. All contain a mix of usable content that should be available elsewhere (e.g. notable critics' reviews) and user-generated content. Even when it's not UGC, it's promotional. Example: IMDB entry for Plandemic is Documentary series about the COVID-19 pandemic that shows the major conflicts of interest between the key medical organizations, the media and their decision makers. Guy (help! - typo?) 09:50, 1 October 2020 (UTC)
• Migrate to {{Authority control}} and use that on all applicable articles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 1 October 2020 (UTC)
  • Oppose moving to authority control. The same arguments against putting in an external link or infobox link apply to adding the same site to authority control; these movie review sources are dodgy, change often, are easily manipulated, and some of them are user generated. --Guy Macon (talk) 20:58, 1 October 2020 (UTC)
• No to all (this includes No to adding them to Authority Control, which should not include even more links and certainly not even more lower quality content: I know that "authority control" isn't supposed to mean "high quality content", but it makes no sense to add links to lower quality content automatically on enwiki, no matter if the link is wanted or useful on Wikidata). In general, the number of ELs (including Authority Control) should be vastly reduced, not increased. (Anyone proposing a bot to get rid of all findagrave and genealogy links to ancestry and the like has my support). Fram (talk) 16:29, 1 October 2020 (UTC)
• No to all - In general, these rankings are too ephemeral to be of any encyclopedic use. The exception is when specific rankings have become noteworthy (such as when there was a significant disparity between rankings by critics vs regular people - enough that the media commented on the disparity) ... but in those cases the specific noteworthy rankings should be mentioned in the body text and cited to third party sources. There is never a reason to link to the ranking site itself. Blueboar (talk) 20:24, 1 October 2020 (UTC)
• No to mass adding all - If IMdB is relevant to direct readers too, it should be added, but definitely not mass added to articles not currently using it. RT and MC will generally exist as inline references so per WP:ELNO, those should then not be duplicated as external links. - Favre1fan93 (talk) 21:16, 1 October 2020 (UTC)

  @Favre1fan93: Which point in WP:ELNO are you referencing? If it's #15, note the explanatory footnote This guideline does not restrict linking to websites that are being used as sources to provide content in articles, which makes pretty clear that the "rule" some editors here seem to want to follow does not actually exist. (If you actually meant WP:ELDUP, please read the above.) {{u|Sdkb}} ^talk 00:21, 2 October 2020 (UTC)

• Yes to IMDb, an explanation concerning Rotten Tomatoes - IMDb first and foremost (despite having the explicitly professional version IMDb Pro) is a database. It provides much much more complete cast and crew lists for basically any movie ever made than wikipedia or any other website provides alongside better release date information and film locations, etc. All but the very largest movies will lack relevant information that IMDb provides. The official website for a film (if it exists) and IMDb I think are explicitly good external links that any notably film should include. As for Rotten Tomatoes I should point out that I am the person that Guy Macon is referring to who "mass added" (i.e. meticulous added by hand over the span of 5 years or so) Rotten Tomatoes links to probably on the order of 5-10 thousand film pages (I would guess, nearly all my edits to wikipedia are either adding or fixing Rotten Tomatoes links). I did it because lacking reception sections on the majority of film pages left no place for readers to go to check the reception to the film, and often the reception section is more of a "reception at the time" and thus either didn't update or had to be updated as more reviews are added over time. I also believe I did my very best to adhere to the policies set forth by Wikipedia over the last five years. All that being said, I understand if maintainers want to change the policy to strictly limit what is allowed in the External Links section of films, some of them are unwieldy to say the least. And Rotten Tomatoes is, I think, much more of a for profit brand than a database, and so I get that my activity could be construed as endorsement. I would argue that conflating Metacritic and Rotten Tomatoes is incorrect though. Much like Box Office Mojo, Metacritic is accessible via any IMDb page (since they share the same parent company, Amazon) and so adding those links alongside IMDb links is somewhat redundant, whereas there isn't (as far as I know) a free service that allows a user to connect IMDb links and Rotten Tomatoes links. It is unclear what changes are specifically being proposed here, but I'll obviously adhere to any policy changes regarding wikipedia external links on film pages. -- LudaChrisKlein (talk) 09:20, 2 October 2020 (UTC)
• I am opposed to mass anything. I would be opposed to rapid, non-editorial (i.e. without regard for the narrative text such reviews were being used to support) adding of these websites to Wikipedia as a semi-automated process. However, I would also be equally opposed to any rapid removal of such links without regard for whether or not they were being used appropriately. I would be also, however, be against enshrining anything in Wikipedia policy or guidance that encourages "mass editing" behavior of any sort. --Jayron32 15:52, 2 October 2020 (UTC)
  • If the link was added to the external links section with no associated text, then there is no "narrative text such reviews were being used to support". And if one editor adds Rotten Tomatoes links to the external links section of a couple of thousand pages, even if they do it by hand, that's certainly "mass adding". So how, exactly, am I supposed to avoid "rapid removal of such links without regard for whether or not the external links to Rotten Tomatoes were being used appropriately"? There is nothing there to "regard" except the external link. --Guy Macon (talk) 16:45, 2 October 2020 (UTC)

• No to all, and should be fine to remove en masse. These are basically spam links. --K.e.coffman (talk) 03:27, 3 October 2020 (UTC)

• No to mass adding, but yes to having them present in the ELs. I'm a little uncomfortable with mass adding anything, but I don't think that we really need to remove the presence of IMDb in the EL sections as a whole. It is useful to have there, as others have stated, and honestly... I've gone to Wikipedia before just to click on the IMDb link for a film, rather than wade through a Google search, since it's not always the top result. I'd wager that I'm not the only one who does that. I don't think it's absolutely necessary to have it in every film article, but if it does eventually get added to almost every article in the EL section that's not necessarily an awful thing as long as it's not used as a source. ReaderofthePack(formerly Tokyogirl79) (｡◕‿◕｡) 05:44, 3 October 2020 (UTC)
• No mass removal I don't think we should mass add them either. ~ HAL333([3]) 03:52, 5 October 2020 (UTC)
  • Would that include a prohibition on reverting a previous mass-addition or mass removal without changing any other pages? --Guy Macon (talk) 06:56, 5 October 2020 (UTC)
    • I think you really need to talk to people more involved in the film part of Wikipedia about this. Not least of which because in the manual of style (https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Film) it specifically says "For example, Rotten Tomatoes and Metacritic can provide listings of more reviews than sampled in the article body. They can be included as external links instead of links to individual reviews." So I think this is much more of a actual policy change than some sort of "reverting a past wrong." --LudaChrisKlein 14:16, 5 October 2020 (UTC)
      • Except that nearly all film pages include RT and MC as part of a reception section (for new films, as a standard part, for older films, predating when RT/MC started, usually as a "contemporary reception" section as well). I've not seen a "well developed" film page that does not use RT or MC in this fashion. --Masem (t) 14:27, 5 October 2020 (UTC)
        • Looking through a small sample (1000 film pages) only about 20% of pages with Rotten Tomatoes links (which is about 90% of film pages) have them as a reference. About 60% have them as external links. The other 20% have them in both places. Those 20% certainly can have the link removed from the external links. The other 60% with links only in external links sections I'm less sure about. If you go to the talk page for that Manual of Style even the presence of Reception sections seems to be a point of some consternation (merely providing RT/MC links being much less maintenance for editors seems to be the gist of the argument against Reception sections in general). --LudaChrisKlein 08:53, 7 October 2020 (UTC)
• No to keep and No to remove. As usual, editorial decisions should be left to editors, not to robots. When watching the series Queen Insoo, the IMDb review is amusing. They are saying that Hahm Eun-Jung (23 yo) appears there during the 60 episodes, as well as Chae Shi-ra (43 yo). The former is playing Insu before 1457, the later is playing Insu afterwards. How could they both appear in each and every episode ? Moreover the review "three women struggle with one another as each vies for power in the royal court", piously reproduced here, at en:wp, is rather misleading. The whole series is a romanced account of a 50 years clash between the hungu and the sarim factions, and revolves around the seizure of power by King Sejo (1417-1455-1468). This series involves more than 250 actors named in the credits and gives a detailed depiction of more than 150 people, a majority of them belonging to real life History. Missing that gives rather the impression that none of both reviewers watched the series. But this is not a plea for a mass removal, since this doesn't prove that other IMDb reviews are pityful to the same level. Pldx1 (talk) 10:13, 5 October 2020 (UTC)
• No Mass Adds This is a terrible proposal which is quickening the heartbeats of spammers everywhere. GenQuest ^{"Talk to Me"} 14:27, 5 October 2020 (UTC)
• Add ELs only when applicable because per WP:EL, we should only include external links when they provide unique resources "beyond what the article would contain if it became a featured article". We should separate consideration of IMDb from consideration of RT and MC. IMDb, while not reliable for citing, has numerous sub-pages of different kind of resources that usually meets the unique-resource criteria. As for RT and MC, it is only happenstance that the inline citation for the aggregate score and the external link for the directory of reviews (which is a unique resource) are the same link. The ELs for RT and MC can more specifically point to the sub-page listing full reviews. But RT and MC do not need to be used if there are no reviews, or if the reviews on either website can be fully sampled in the Wikipedia article body. For example, if a film has only eight or nine reviews on RT/MC, then these can be sampled in the reception section, and no EL is needed. I think other editors need to be more nuanced beyond just saying that because RT/MC is used as an inline citation, it shouldn't be used as an EL either. The ELs exist to provide access to more reviews. Erik (talk | contrib) ^{(ping me)} 16:40, 5 October 2020 (UTC)

  Very well put. {{u|Sdkb}} ^talk 17:14, 5 October 2020 (UTC)

Things I am finding alongside IMDB and Rotten Tomatoes

There are some other external links that I am finding alongside the movie review website external links discussed above. What should I do if I run into the following? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

YouTube of the entire film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

This seems like a clear copyvio, and I have removed them when I found them. --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Keep in mind some short films may be uploaded by the owner of the work, which would be valid. But you need to cross check and confirm the account owner, they hold the rights, etc. If this all checks out, this would be okay, it would be akin to linking to the music video uploaded by the copyright owner (legit) on the WP page about that song. But 999 times out of 1000, for film works, the upload of the full work is likely a copyvio of some means or another.

Films/works confirmed to be in the PD should be kept, though ideally we should go to a source like Archive.org where these are better preserved. For example [4] for Manos: The Hands of Fate rather than any YT version. --Masem (t) 16:55, 2 October 2020 (UTC)

YouTube of a scene from the film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Nope, unless the scene is extremely well-known to the point that the film is primarily known for the specific scene, and the YouTube license is clear. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Any scene from a film (non-PD) that is a subject of discussion should be used as a non-free media file encoded and trimmed per our NFC policies and used as a File: directly. --Masem (t) 16:57, 2 October 2020 (UTC)

And of course if it is only found in a link in the external links section, it isn't a subject of discussion.

Public domain movies are something I didn't mention above. What about an external link to a YouTube copy of a scene or even an entire film from 1913? At first blush this seems OK, but I think it should be disallowed for the following reasons: [A] any YouTube video can be taken down at any time. [B] many of these old public domain silent films have been released on DVDs with added music or maybe just an introduction that is copyrighted. [C] Many YouTube videos have ads inserted in the in the middle of the content. Besides being undesirable just because they are ads, the ads are not PD. [D] Someone is making money off of that YouTube video, and if we link to it we are encouraging spamming more of the same to make more money. None of these problems apply to a file without any added copyrighted material that we host on commons. --Guy Macon (talk) 17:47, 2 October 2020 (UTC)

Which I all agree with. Its better to use a commons version or Archive.org version than YouTube which may remain questionable. --Masem (t) 21:39, 2 October 2020 (UTC)

YouTube of a trailer for the film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Not so sure about this. Doesn't the copyright holder want as many people to see the trailer as possible? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Hmm, perhaps. Seems a reasonable enough EL. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Perhaps it should be restricted to "official" trailers if possible, just to mitigate the risk that the YouTube link will break in the future if the video is taken down (this is a particular problem on TMDb I encounter on occasion). But I tend to agree that a trailer is a good EL that can't really go into the body of the article as a reference.--LudaChrisKlein (talk) 09:39, 2 October 2020 (UTC)

I would not include this normally. If the trailer is the subject of discussion beyond just when it was released , we have {{external media}} that can be used to embed a box to direct people to see that near where it is discussed. (eg not a movie but this is used in Untitled Goose Game where the trailer is discussed related to how its popularity and music impacted its development). --Masem (t) 16:15, 2 October 2020 (UTC)

Trailers are ads and ads are not encyclopedic, thus they violate WP:ELNO and shouldn't be included. (This is different to a discussion about a trailer, but then that would be reliably sourced with secondary sources.) —  HELLKNOWZ   ▎TALK 16:24, 2 October 2020 (UTC)

Agree with HK 100%. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)

OK, unless someone gives me a compelling argument to the contrary, I will remove external links to movie trailers on YouTube when I run across them per Masem and Hellknowz. --Guy Macon (talk) 16:36, 2 October 2020 (UTC)

Facebook page? Twitter account? (Example: Whole Lotta Sole#External links) --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

My big question here is whether I would have to research to see if the account was official. --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

I think you would. Facebook accounts are at least sometimes official especially for smaller films. I do think you'd want to confirm that they aren't official before removing them. --LudaChrisKlein 08:49, 2 October 2020 (UTC)

Way easier said than done. There are probably hundreds of thousands of such accounts, how do you get editors to check each one before changing? You don't, because ain't nobody got time for dat! We should not be using FB or Twitter in any capacity on Wikipedia in my opinion, or only in very rare instances where they may actually be the article subject. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)

If there's an official website, that's sufficient; no need for the Facebook and Twitter. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Sorry if I was unclear, I agree. But the issue is that you can't just remove all Facebook links because some of them will be the official site. If there is another official site in the external links then yes, I think you can remove the facebook link without checking. But whether Guy will have to "research if the account was official" I think the answer is generally yes. In my experience facebook accounts are not typically included in External Links sections, and so when they are (and no other official website is listed) I think you'll definitely have to check to make sure it isn't the official website for the film. --LudaChrisKlein (talk) 09:24, 2 October 2020 (UTC)

Link to Getty Images or any other image hosing site? (Example: Whole Lotta Sole#External links) --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

I would just consider the official website and the IMDb page to be somewhat-essential as part of External links. El Millo (talk) 22:51, 1 October 2020 (UTC)

Official website, yes; Imdb, not always. Can someone tell me why we locked into IMDb and not some other publicly edited movie site. I think they all should probably go in most cases. At the least these EL entries should be limited to just one per article. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)

Can we get an example of an image hosting site in the external links section? I can't really think why something like that would belong in external links, but maybe in some cases. --LudaChrisKlein (talk) 08:51, 2 October 2020 (UTC)

I'm confused as to why this would be present, same as Luda. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Grant Crabtree#External links and Women's American Basketball Association#External links have links to photobucket. Both photobucket pages have been taken down, so I assume that they were not official pages. If somebody put links to now-deleted photobucket pages in the external links to those two articles, I am pretty sure that an exhaustive search would turn up some examples of external links to pages from photobucket or other image hosting sites that haven't been taken down yet. --Guy Macon (talk) 16:10, 2 October 2020 (UTC)

Template:cite web: A new parameter for url-access

In template:cite web, under Subscription or registration required, the url-access parameter should support indicating that access is permitted via the The Wikipedia Library Card Platform.

I realize that there are some considerations regarding this approach:

• Access is not universal, but rather depends on the ongoing accomplishments, and in some cases the successful application, of the individual editor.
• Access to a database may shift, as it can withdraw its participation.
• Access to a database might be limited to a specified number of editors.
• An editor might attempt to game the access requirement by making many trivial edits.

However, there is also a potentially positive aspect: potential users of the Library Card might be incentivized to be more productive in their Wikipedia efforts. Larry Koenigsberg (talk) 20:45, 2 October 2020 (UTC)

Oppose per WP:READER. {{u|Sdkb}} ^talk 21:14, 2 October 2020 (UTC)

I think I would oppose because there is very little guarantee that TWL will always have the same access to the various databases it currently enjoys. --Izno (talk) 21:17, 2 October 2020 (UTC)

Oppose The content of pages in article space should be useful to readers, but anything about The Wikipedia Library is only useful to editors. Jackmcbarn (talk) 21:01, 4 October 2020 (UTC)

Oppose per above. BUT it would be nice if there was a way like how we have Special:BookSources for when we link ISBN's , that we could do the same for DOIs and other academic papers so that a reader and/or editor can determine if they have access quickly. But this would be outside the template's ability. --Masem (t) 15:37, 5 October 2020 (UTC)

Turning user-rights off and on at will

I propose a user-preference or other mechanism that will let editors enable and disable advanced user rights they hold as needed.

Why?

I hold autopatrolled and pending changes reviewer user-rights. There are times I wish I could turn them off either for a particular editing session.

I don't think there is a way to do that short of having two accounts or logging out. If I'm wrong, please let me know.

Please reply if you would benefit from such a setting. If there is enough support I'll make a formal feature request. davidwr/(talk)/(contribs) 16:21, 4 October 2020 (UTC)

• I can't speak for others, but I have to say this wouldn't really be at the top of my priority list, given how many more pressing technical requests the community has. It's always possible to log out to see what editing is like without a given user right. {{u|Sdkb}} ^talk 16:40, 4 October 2020 (UTC)
• I am curious as to why anyone would want to toggle their user rights off... is there a benefit? Blueboar (talk) 16:49, 4 October 2020 (UTC)
• Testing how things look/work for a user with different permissions is often a thing in software/interface/etc development, but very rarely is something other than admin, regular user or logged out necessary (at least in my experience as an admin). Logged out is obviously very easy to see, and often admins will have a second account for use on insecure connections they can use for this purpose (I use Awkward42). About twice in the last 5 years there has been an occasion where I've wanted to check how something looked to an administrator who wasn't an oversighter (I can't remember the details of why), but on both occasions I happened to be in the same physical location as someone who fit that bill. On the whole I don't think that a feature to allow switching of user rights like this would be worth the effort of making it. This is especially true because any such tool would need to be able to determine whether you don't have a particular user right because you removed it yourself, because someone else removed it or because you never had it. I would be very surprised if this is currently tracked, so it would likely need two record at least two states (not held because you removed it or not held for some other reason) for every unheld right (there are about 28 rights it is possible for en.wiki users to have) for every user. Thryduulf (talk) 20:43, 4 October 2020 (UTC)
• Just open Wikipedia in a private browser session. You could even directly compare your logged in window to the private one. VanIsaac_WS^cont 20:49, 4 October 2020 (UTC)
• Note that the software already supports this, so we'd just need to request configuration changes if we wanted it. What we'd do is create a new group called "autopatrolled-available", and then add "autopatrolled" to "$wgGroupsAddToSelf['autopatrolled-available']" and "$wgGroupsRemoveFromSelf['autopatrolled-available']", and similarly for the rest of the groups we wanted to do this for. Then admins would just grant the -available group along with the main group. Jackmcbarn (talk) 20:56, 4 October 2020 (UTC)
  • @Jackmcbarn: Do any other wikis use this scheme? What might be the downsides? If it's benign and has worked well elsewhere, I think it might be worth trying even if it has a narrow use case. — Wug·a·po·des​ 19:33, 5 October 2020 (UTC)
    • I can't think any wiki does something as extensive as is proposed here, but the closest analogue is the translation administrator right on multilingual wikis, which admins can grant and remove from themselves, but only bureaucrats can grant or remove from other users. That's not caused any problems in my experience. For what it's worth, I think this proposal is complexity creep unwarranted by its benefit. * Pppery * _{it has begun...} 20:33, 5 October 2020 (UTC)
• OK so this is technically possible, looks to some editors including myself to be an unnecessary complexity, I think we need to see other editors say why they think it would be useful before it is worth taking further. Disclosure - I sometimes do or assist at training, usually as the tame admin setting accounts as confirmed, but I get why trainers need an account without userrights to demonstrate things to newbies; However, that's what declared alt accounts are for...... So this is a solution to a problem that already has a solution, unless others see advantages to it? ϢereSpielChequers 08:07, 6 October 2020 (UTC)
• I am struggling to find a use-case that could not already be handled by our present system using two accounts. For example, I currently have the following rights: extended confirmed user, file mover, IP block exempt, new page reviewer, pending changes reviewer, rollbacker. I also have an alternate account with a long random username (don't want to use up one of the good names) and no user rights that has never edited that I use for seeing how pages look to a newly-registered user. Let's say that for some reason I decide I want to run an editing test with my rollback turned off but IP block exempt left on (If they ever let me leave the US again I will need that to edit from the Tails OS when I am in China). I could simply create User:Guy Macon Alternate Test Account E694E42C05C5995D7D613720520A9C69146F544F18C80F5, slap an alternate account notice on it, and ask an administrator to copy my user rights over but without rollbacker. No turning user-rights off and on needed. --Guy Macon (talk) 10:18, 6 October 2020 (UTC)
• See phab:T153454 and phab:T210909 which incorporate aspects of this, both are basically stalled. — xaosflux ^Talk 10:51, 6 October 2020 (UTC)

Move good/featured article topicons next to article name

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

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

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

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

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

Support Seems like an improvement to have the icon right next to the article title to make the meaning more clear. Having review icons next to names is becoming more common recently,(e.g. Twitter and Youtube verified accounts) so it makes sense to evoke some of that design language, since GA/FA also involves a kind of external review. Without knowledge of what a GA/FA is, it's not obvious from the current context what the function of the icons is. Seems like a clear improvement for WP:READER who isn't familiar with Wikipedia's internal article review process. 〈 Forbes₇₂ | Talk 〉 15:06, 6 October 2020 (UTC)

• Support increased prominence for GA/FA icons, per the nom's excellent rationale. I'll need to think/research/hear out others a bit more before committing to this specific remedy, but we certainly ought to do something. {{u|Sdkb}} ^talk 16:36, 6 October 2020 (UTC)

  Clicking through to Danish Wikipedia, the icon there looks fantastic, so I'm moving to full Support unless anyone comes up with a better idea for how to display the icons to give them more prominence. {{u|Sdkb}} ^talk 00:42, 7 October 2020 (UTC)

• For some reason, it doesn't show when using the Timeless skin. If that can be solved, I'd consider supporting. Isabelle ^🔔 22:39, 6 October 2020 (UTC)
• Oppose I'm sympathetic to the arguments provided, and I do agree with most of the rationale, but I'm opposing because I think the current way of doing it is more aesthetically pleasing. I think that putting it right next to the article title does look a bit obtrusive. As a side-note, regulars of the FAC and GA processes should probably have been notified of this discussion here and here. Ichthyovenator (talk) 22:54, 6 October 2020 (UTC)

  Ichthyovenator, I notified WikiProject Usability, which is probably the most relevant WikiProject, even though it's not super active. The GA and FA folks have now been notified as well.

  Regarding your opposition, do you have any ideas about alternative ways we might emphasize FAs/GAs? {{u|Sdkb}} ^talk 23:04, 6 October 2020 (UTC)

Sdkb I personally really like how it is handled now but I do see how someone not familiar with Wikipedia and the FA/GA process would miss the icons. What I'm fearing is that putting big icons next to the article titles will make it look cluttered. I can see that I'm clearly in the minority here; maybe i just need to see some concrete design suggestions, it is probably possible to move the icons as per your suggestion without making it look cluttered or obtrusive. Ichthyovenator (talk) 10:22, 7 October 2020 (UTC)

• Support. Including GA articles. Current icons are not really visible, especially on the mobile site. T8612 (talk) 23:00, 6 October 2020 (UTC)
• Support You are right. The icons remains unnoticed by the common readers. I noticed that, here, in India, most Wikipedia readers don't know what the GA and FA are. --Gazal world (talk) 23:02, 6 October 2020 (UTC)
• Support placing alongside article title in mobile view. I think the current arrangement for desktop is ok though. Peacemaker67 (click to talk to me) 23:09, 6 October 2020 (UTC)

  @Peacemaker67: Sdkb has pointed out this is currently a technical limitation on mobile. My issue with desktop is I don't feel that reader's eyes naturally go to the top-right corner when they open and read an article, particularly if they're doing so quickly. Jr8825 • Talk 00:44, 7 October 2020 (UTC)

  I've commented there. I'm not sure I like the idea of sitting the star next to the article title in desktop though, mainly from an aesthetic/professional appearance perspective. Peacemaker67 (click to talk to me) 00:55, 7 October 2020 (UTC)

• Support - I like this idea. — Rhododendrites ^talk \\ 23:13, 6 October 2020 (UTC)
• Weak support I think it's probably better for the reader, but I don't like it as an editor. Full support for placing alongside title in mobile view. Seems like a pretty simple thing to do, happy to expand on my rationale if wanted. Eddie891 ^Talk _Work 23:31, 6 October 2020 (UTC)
• I don't agree with the premise. I don't think additional prominence is required for the good article/featured article icons. Readers are very good at judging the quality of articles on their own, without needing more intrusive cues. isaacl (talk) 23:54, 6 October 2020 (UTC)

  I'm not saying that readers can't judge the quality of an article (although I would probably disagree with you about how easy it is to do this as a reader), it's that I suspect many people are unaware that featured/GA content exists and that this means most of the text will have been peer-reviewed and undergone some methodical scrutiny, unlike the majority of articles. It also tells readers what to expect, rather than requiring them to pick up through their reading whether an article is accurate or not. Jr8825 • Talk 00:05, 7 October 2020 (UTC)

  My personal view is that most readers give their own personal judgment greater weight than an internally assigned icon, and thus the icon doesn't need additional prominence. isaacl (talk) 00:18, 7 October 2020 (UTC)

  @Isaacl: I'm with Jr8825 here; I strongly disagree that readers are sufficiently aware of the GA/FA system. Ask a non-Wikipedian in your life how the website indicates its highest-quality articles, and I suspect most people will be stumped. Similarly, ask them whether it's better for an article to have a bronze star or a circled green plus sign, and most won't have a clue. There's more than a little tragic irony when you think about it: we put a massive amount of effort into identifying which articles are worthy of being designated with our quality markers, yet because our user interface is so terrible, the 50% of readers on mobile don't see them at all and most of the desktop readers miss their meaning. {{u|Sdkb}} ^talk 00:39, 7 October 2020 (UTC)

  My assumption is the icon isn't visible enough to some readers to notice/process it, so it's not being factored in to their judgements at all. And my other presumption is that encouraging readers to be aware of and consider FA/GA status when they decide how much they trust what they're reading is generally a good thing. Jr8825 • Talk 00:46, 7 October 2020 (UTC)

  I agree that in all probability, many readers are unaware of what a bronze star or circled green plus icon means (that would be another worthwhile discussion: are there better icons or some other indicators that can be used?). In my view, though, I think readers place more importance on their own judgment than the evaluation of a pseudonymous set of persons within the Wikipedia community, and so giving the icons more prominence is unwarranted. isaacl (talk) 00:47, 7 October 2020 (UTC)

  On that tangent, to communicate article quality to readers, a familiar paradigm (1-star, 2-star, 3-star, 4-star) would be most recognizable and more easily understood than abstract icons. Use 1 for stub/start/nonrated, 2 for B/C, 3 for GA, 4 for FA. Schazjmd (talk) 00:58, 7 October 2020 (UTC)

  In such a scheme, I maintain that the distinction between B, C and GA is indistinguishable; they are all adequate at best, dangerous at worst. SandyGeorgia (Talk) 01:29, 7 October 2020 (UTC)

  I've been thinking about launching an initiative to redesign the GA/FA topicons for a while. You've inspired me to kick it off at the graphics lab: see Wikipedia:Graphics Lab/Illustration workshop#Good article and featured article topicon redesign. {{u|Sdkb}} ^talk 05:14, 7 October 2020 (UTC)

• I would support for mobile view (though note the subsection below) and am neutral on desktop view - other suggestions for prominence per Jr's rationale may be a better idea, unless the icon is put before the title to maintain a standard alignment. Kingsif (talk) 00:29, 7 October 2020 (UTC)

• Strong oppose: this is a well intentioned but very bad idea because it will mislead our readers even further. (As a regular FA participant, who also edits medical FAs, this potential misleading of readers would be critical wrt our medical content, most of which is not up to FA standards. See User:SandyGeorgia/sandbox2#Medical FAs.) We will be sending a more prominent signal to readers that the articles with some sort of icon next to their name have been checked, vetted, reviewed, or are somehow better than other other articles on Wikipedia, but those readers won't necessarily have the skills or knowledge of Wikipedia to understand in what circumstances those icons are (or mostly, are not) still valid. Average readers probably don't know how to check the article milestones to discover when the article passed content review, whether the original authors are still actively engaged, whether the article has changed substantially since it passed content review, and whether the pass was a good one even when it occurred. With months-long efforts at WP:FAC and WP:FAR to get editors to actively engage in reviewing our out of compliance and very old FAs at Featured article review, we still have a considerable backlog of unreviewed older FAs (many more than those for which talk page notice has been given), and basically, no one is interested in engaging at FAR to deal with them. The situation with GA is even worse, as they start out as one person's opinion, and ... I can't even remember how long ago the last GA sweeps were. The situation now is obscure; the average reader probably doesn't know how an article is rated. But telling them more prominently that an article is well-rated when at least one-third of our FAs are not, and GAs were never more than one person's opinion, would mislead them even further. Article assessment is an internal matter that experienced editors know how to interpret: we can go to the talk page, look up the history, and say, "Oh, that article was passed ten years ago on only three supports, it has grown to twice the size since then, and the original editors are no longer watching, so the article has taken on lots of inaccurate cruft". The average reader might not be able to do that. We should keep assessments as an internal matter, that experienced Wikipedians know how to interpret. That the average reader doesn't know what the icon in the upper right hand corner means is just fine; let's not make a more prominent, and misleading, statement about the quality of our pool of GAs or FAs.
  Oh, and please go and nominate some articles, and review some articles, at WP:FAR. The pool of FAs is only as good as the worst of them. SandyGeorgia (Talk) 00:50, 7 October 2020 (UTC)

  I completely understand where you're coming from, the reason I feel differently is that I feel making FA/GA content more visible may encourage readers to understand how Wikipedia works better, particularly if they're encouraged to click on the icon and read more about how featured content works (see the example on the Danish Wikipedia, which has a tooltip saying This is a featured article. Click here for more information). Then all that's needed is a better explanation of what featured content is at WP:FA, as the current text just makes it sound like it's perfect. Honestly, I can imagine this being a great way to spread awareness to readers about how Wikipedia really works - i.e. any revision can be good or bad. Ed: And to me, it seems pointless putting in all the effort of ensuring FA articles meet FA quality, if readers are completely oblivious to their existence. Jr8825 • Talk 00:54, 7 October 2020 (UTC)

  I also can't see why such a tooltip couldn't say 'A version of this article was assessed as Featured in January 2010. Click here for more information'. Jr8825 • Talk 01:01, 7 October 2020 (UTC)

  That won’t work either. That would send our readers to a dated 2006 version for Tourette syndrome, which I have constantly maintained and overhauled. And, for a GA example, it would send our readers to the embarassing GA pass which misidentified a well know historical figure, Douglas MacArthur. I can provide worse examples of GA issues; I have already provided a list of medical FAs with issues. SandyGeorgia (Talk) 01:24, 7 October 2020 (UTC)

  Sorry, just to clarify, I didn't mean that the icon should send them to an old revision, just that the tooltip could also indicate when the assessment was made while encouraging viewers to click through (linking to WP:FA as it currently does). Jr8825 • Talk 01:27, 7 October 2020 (UTC)

  Same, regardless. Tourette’s passing in 2006 might imply it is no longer at standard. Which is misleading. SandyGeorgia (Talk) 01:32, 7 October 2020 (UTC)

  Perhaps 'This article reached Featured status in January 2010. Click here for more information'. (The German Wiki uses similar text.) Although I'm not sure whether it's a bad thing to say that a previous version was judged as standard, after all it's the most accurate statement and helps shows how much Wikipedia's quality varies with revisions. Jr8825 • Talk 01:35, 7 October 2020 (UTC)

  I think this is a perfectly reasonable concern about FAs, but it goes way beyond the scope of this discussion. What you seem to be proposing is that FAs/GAs have become so unreliable that they should not be considered reader-facing. Perhaps that's true, but that's a much larger discussion that would entail removing the topicons entirely and eliminating links to reader-facing pages like WP:Featured contents. For better or worse, the system we have right now is one that commits to making featured designation visible to readers, and so long as that's the case, we should make it work well enough that readers are aware of it as intended. If you want to change the fundamental purpose of the featured content system, you'll need to start a separate discussion about that. {{u|Sdkb}} ^talk 02:13, 7 October 2020 (UTC)

  I don’t believe I have typed what you are reading. SandyGeorgia (Talk) 02:39, 7 October 2020 (UTC)

  Finishing the thought. It is not a "concern about FAs"; it is a statement of fact about GAs and FAs, and a reminder that our processes only work if people use them. Participation has fallen off at FAC and FAR, while GAR is practically unheard of, relative to the numbers of old GAs. IIRC, GAs were last re-evaluated ten years ago. Wikipedia does not regularly re-assess articles at any level, and shouldn't pretend to our readers that we do (but on that score, FA does a better job than GA).

  Reading Wikipedia:Wikipedia Signpost/2008-06-23/Dispatches (How Wikipedia's 1.0 assessment scale has evolved) may help you understand that assessments are, and always were, internal processes, best understood to experienced Wikipedians, and unlikely to be understood by others.

  Sticking a link to WP:FA or WP:GA next to an article title is not going to increase reader knowledge about the pros and cons of those processes, or help them understand how to interpret them. Experienced Wikikpedians can look at a GA pass and say "that was a good pass" or "those were bad passes". Or that was passed so long ago, and the article has changed so much, it's no longer relevant. We are to serve the reader; giving them a link to something meaningless to them—while potentially misleading them about quality—does not serve the reader. And the only difference between B-class and GA-class is exactly one editor's opinion.

  As to how to best use this page, it might have been more productive to first get feedback and ideas at WT:FAC or WT:GAN before proposing something here. SandyGeorgia (Talk) 13:22, 7 October 2020 (UTC)

  You bring up some valid concerns here, but the discussions about the lack of participation in GA/FA, or whether GA/FA icons should be reader-facing at all are separate questions altogether. I appreciate your efforts to address broader issues with the review system, but this proposal just a narrow question about the location of icons on a page. The question is whether the upper right or next to the article name is a more clear location. You're right that there are other issues with the review process that need addressing, so I hope eventually we can address those other problems as well. 〈 Forbes₇₂ | Talk 〉 17:58, 7 October 2020 (UTC)

• I realize our icons our different, but the Danish example above reminds me a lot of blue checkmarks on Twitter (I'm not saying it's a bad thing, just a thing). As an alternative, we could put the icons to the left of the title but still right next to it. -- Calidum 02:28, 7 October 2020 (UTC)

  They have an extra tier below good article ("promising"), my first example wasn't the best as it's from that category. You can see a GA here. Jr8825 • Talk 02:33, 7 October 2020 (UTC)

• Oppose Rearranging icons is not helpful. We should assume that readers are interested in article content, not how attractively the icons appear. It won't help a general reader to see that a particular article is GA or FA or other, and the icons raise questions that distract from the content. Also, positioning the icons requires Javascript that seem unnecessary. Johnuniq (talk) 04:07, 7 October 2020 (UTC)

  My point is not about attractiveness. It's about whether a GA/FA icon is of any use to a reader (it seems I disagree with you, as I think it is helpful for the general reader) and whether it should be more visible. Jr8825 • Talk 04:30, 7 October 2020 (UTC)

• Just a note on the point of ~"non-Wikipedians don't care." In talking with hundreds of academics about Wikipedia over the years, including a whole lot of instructors who want to learn in order to help students learn about a site they use every day, they are almost invariably surprised to learn about GAs/FAs. They value these little symbols because it's one more tool in the information literacy toolbox that allows people to understand the content they're reading. It's not the only tool by any means, or even the primary tool, but the sheer volume of people who say (a) I never noticed that, and (b) that's very useful tells me changing the position may help.

On the subject of whether it would make any difference: Rather than just speculating that this would be helpful, though, maybe we should test it out. Wikipedia doesn't use cookies like other sites, but we can experiment in other ways. For example, display a topicon that links not to WP:GA but to a dedicated subpage of the article it's displayed on with similar information. Check the pageviews after a month, move it closer, check pageviews after a month. Something like that? — Rhododendrites ^talk \\ 13:22, 7 October 2020 (UTC)

• I agree with you generally, having also encountered this issue. But I view it not as a problem, rather as a good thing-- that the average reader is not misled into believing that every GA or FA they access is somehow recently vetted and approved. How about if someone were to run a bot and determine the dates on all of our GA passes; I wonder what that would reveal relative to the GA sweeps of a decade ago. I don't see it as helpful to mislead our readers into thinking that when they access a GA, they are necessarily accessing a dependable, reliable article. Also, I'm not sure what would be on this subpage your suggest? As in the examples I give above about Tourette syndrome ... we could at best show at 2006 FA pass, which doesn't address that the article is constantly overhauled and updated, compared to some 2010 to 2013 medical FAs that are now outdated. What would say on this subpage that would be digestible and understandable to a reader who doesn't understand the vagaries of a project that "anyone can edit", and where editors who once labored over the quality of an article move one, and the article goes to crap? SandyGeorgia (Talk) 15:33, 7 October 2020 (UTC)

• It seems like there are a few different things here. It would be good to have a process of reviewing promoted articles on a set basis, but as I think you were getting at above, we don't have the volunteer resources to keep up with the current backlog of initial reviews to begin with, nevermind re-reviewing. It's probably something best handled on a project basis, since there are a lot of historical articles, articles about books/media, etc. that don't really change much in 10 years while medicine, political figures, etc. certainly may. But on the next question of what could go on the subpage: I think it would be useful to explain what GA means, what it doesn't mean, and, along these lines, set expectations accordingly. A bot should be able to automatically create these fairly easily I imagine, including different blocks of text depending on how long ago the review was. Maybe even a faded icon if, say, 10 years have gone by. Maybe a link to the version that was reviewed and a link to the review itself. Of course that stuff is already on the talk page, but I think people would be far more likely to click a shiny icon next to the title than to find it in a sea of banners on the talk page. And the way we present it on the talk page doesn't provide much context. We can't really expect readers to click more than one additional link IMO... (I'm spitballing, in case it's unclear). — Rhododendrites ^talk \\ 16:24, 7 October 2020 (UTC)

• Oppose. While our FA process is helpful editorially, the tag necessarily ends up being applied unevenly. So many great articles are not FAs, and some that are, are not really that great. Making the FA tag more conspicuous will mislead our readers into thinking it has been uniformly applied, when in fact it hasn't. Paul August ☎ 15:12, 7 October 2020 (UTC)

It's fair to point out that a featured article isn't necessarily better written than any other article, it's just an article that has passed review. Ideally, I think we all wish that FA and GA status was a more reliable measure of relative article quality. However, even when that is not true, passing a review is represents the article has at least a certain level of absolute quality. We can work improving throughput for the FA/GA review, but let's not wait for a perfect process if the current one is already a net positive. 〈 Forbes₇₂ | Talk 〉 17:20, 7 October 2020 (UTC)

• Do not use icons at all. The above comment from Rhododendrites is anecdotal evidence that readers often do not "notice" the icons at all. Label a Featured Article with the text "Featured Article" and a good article with the text "Good Article". Extend these labels to give the date when the status was awarded and have the status "fade" over time. — GhostInTheMachine ^{talk to me} 15:24, 7 October 2020 (UTC)
• Oppose. Admittedly, I'm a little biased in that I have the gadget that changes the header color to match the assessment, but leaving aside that I share some similar concerns as Sandy. I think the comparison made upthread about "verified" badges and similar is a solid one, but my concern dovetails with that connection—FAs are generally quality work, but literally putting the star or plus side right next to them implies a level of official certification that is writing a check we can't back up. Der Wohltemperierte Fuchs ^talk 23:11, 7 October 2020 (UTC)
• Support A/B testing the idea per Rhododendrites. These icons help with advancing information literacy by alerting readers to the state of our content in the same way that all of our cleanup-banners do. There is a very real possibility that this could actually improve not only reader engagement, but create a greater incentive for editors to use the content review processes. We should be able to test it out on a few pages to see if the change causes the effects we want. We could create Wikipedia:Good article topicon placement test control and Wikipedia:Good article topicon placement test manipulation as a redirects to Wikipedia:Good articles. For pages in the control group, the topicon would be in the usual place, and for those in the manipulation group, the topicon would be closer to the title. If changing the location is actually effective, we should see more page-views in the manipulation group than the control after a few months (normalized by daily page-views probably since some people will click on things just because it's new). We could even do second round tests where one of the redirects is turned into a reader-facing info page on our quality review processes, or add links to the article's review page so readers can easily audit our review processes and come to their own decisions about the reliability of the quality rating. We should come up with a testing plan before doing this, but I think this is an interesting enough idea to try it out for a bit. — Wug·a·po·des​ 01:01, 8 October 2020 (UTC)
• Support A/B testing the idea per Wugapodes. I personally don't like the idea aesthetically, but we should focus on function over form, and testing the idea a bit seems entirely reasonable. On a separate note, I maintain* the "metadata gadget" that retrieves article ratings and highlights them in the tagline and title, and highlighting article ratings in an icon or icon-like format beside the title was a proposal that MGalloway made while employed at the WMF, with the idea that it would help colourblind users. I rejected the idea at the time: icons requiring a hover interaction would be strictly worse than the current text-focused approach of "put all the info as text in the tagline and provide 'bonus' colouring in the title". However, she mocked up some ideas that are to date still unarchived at MediaWiki talk:Gadget-metadata.js, which might be relevant here for design purposes. (*I haven't done much recent maintenance at all, in part because I haven't picked up the interface admin right I'd now need to edit it directly, but that's a different story.) {{Nihiltres |talk |edits}} 17:41, 8 October 2020 (UTC)

Mobile display

Tracked in Phabricator
Task T75299

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

• OK. The lack of mobile topicons on mobile is highly problematic. Readers need to be easily able to see what the quality of the article they are reading is. I don't use the mobile version often, but am aware that many readers do. This should be a high priority in terms of development, as article quality is at the centre of what we do on WP. Peacemaker67 (click to talk to me) 00:51, 7 October 2020 (UTC)

  Agreed. I commented on the phabricator ticket, but I've never quite figured out how to boost a development task's priority; it seems to be mainly up to the whims of the WMF folks. {{u|Sdkb}} ^talk 01:57, 7 October 2020 (UTC)

  Most developers are volunteers like you, not WMF employees, so the best way to increase a task's priority is to volunteer to fix it. Creating a phab task is like placing a cleanup template on an article: unless you plan to fix it yourself, the request will probably just languish until someone cares enough to get around to it. Unlike cleanup tags, there's far fewer hands on deck to fix non-critical phab tasks. — Wug·a·po·des​ 01:10, 8 October 2020 (UTC)

Add it to the {{Short description}} like this. It will appear in the search but, like the short description, it will not appear at the top of the page. Or you could have another template that could use "FA", "GA", "Polar bear liver", etc and explain what the ratings mean. CambridgeBayWeather, Uqaqtuq (talk), Huliva 14:40, 8 October 2020 (UTC)

RFC for Improvements to TransDigm Group article

There is a request for comments taking place at Talk:TransDigm_Group#RFC_for_updating_TransDigm_Group_article regarding Improvements to the TransDigm Group article. --Jax 0677 (talk) 18:32, 6 October 2020 (UTC)