Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.

Please see this FAQ page for a list of frequently rejected or ignored proposals.

« Archives, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192

Social Media Statistics

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

---

Social media statistics, such as subscribers, followers, likes, and views may not be used in infoboxes or lead sections and may not be used to establish notability. When it has received significant coverage from an independent reliable source these statistics may be used sparingly in the body of an article accompanied by the month and year that the number was reported. Best wishes, Barkeep49 (talk) 00:05, 15 February 2019 (UTC)

Support (social media statistics)

1. Social media networks like Instagram, Twitter, Twitch, and YouTube have experienced persistent problems with the reliability and accuracy of statistical measures. This has meant inflated follower/subscriber counts and paid for or bot generated inflation of the count of individual pieces of content such as views on YouTube or likes on Instagram. This has been a problem for many years (see efforts in 2012 to counter on Youtube or on Twitter in 2014) and remains a problem today (sample of stories from 2019: [1] [2]). On Wikipedia these pieces of information are often used to promote article subjects rather than inform readers. Further they are frequently cited to the social media networks themselves which can be hard to verify as these numbers fluctuate. There is no policy or guideline support for use of these numbers to establish notability; social media influencers and online streamers normally are proved notable through use of the general notability guideline. Best wishes, Barkeep49 (talk) 00:05, 15 February 2019 (UTC)
2. Well-worded. A blanket ban wouldn't be appropriate and neither would a blanket inclusion. The context, namely, the notability of the individual and whether YouTube etc is their only endeavour all come into play, meaning application on a case-by-case basis is the best way forward. SITH (talk) 00:13, 15 February 2019 (UTC)
3. Full Support. I fully support this move. Half of all web traffic on the Internet is just Bots. It's time to stop fooling ourselves. None of these statistics are going to be reliable. Large numbers should not replace Reliable Sources. Thank you all for your time. ―Matthew J. Long -Talk-^☖ 02:35, 15 February 2019 (UTC)
4. Support. Particularly because I think the second sentence is a good standard. If a follower count is seen as newsworthy by reliable sources, it should be included as far as it is due. Otherwise, it's more of a piece of trivia. Natureium (talk) 03:53, 15 February 2019 (UTC)
5. Support the big problem for leads and infoboxes are that these are about impossible to keep up to date. On top of that, as barkeep has pointed out, there is significant manipulation of these numbers and they don't really tell us that much and are highly unreliable. Combine that with the fact that we are not an advertising platform for YouTubers, and I think the weight of the arguments is strongly against these.
   In terms of the body, if high quality sourcing thinks it is significant, we can cover it, but on its own, the numbers are meaningless. TonyBallioni (talk) 07:05, 15 February 2019 (UTC)
6. Support It trivial, largely unreliable and not even sure it tells us how popular someone is.Slatersteven (talk) 11:28, 15 February 2019 (UTC)
7. Support per all above. I call social media stats "spammer metrics" because their primary audience is marketers and advertisers. They only exist to promote the subject, and are not reliable encyclopedic information. The livelihoods of influencers depend on spammer metrics, so that companies can justify spending their marketing budget on them. The platforms have an incentive to look the other way regarding fake likes because they too use spammer metrics to justify growth and audience size to investors and advertiser clients. A simple Google search demonstrates that padding social media stats is surprisingly cheap (about a cent per like) and there is a whole cottage industry dedicated to it. MER-C 11:45, 15 February 2019 (UTC)
8. Support These are bullshit statistics. By itself, absolutely unreliable for proving anything about notability. If someone else comments on it, fine to use, as always, but we add to the problem by reporting these numbers. valereee (talk) 13:09, 15 February 2019 (UTC)
   • @Valereee: This policy would prevent us reporting on these numbers, regardless of their reliability, notability or commentary in secondary sources. Thryduulf (talk) 10:40, 19 February 2019 (UTC)

     Thryduulf, I think it only prevents using them in leads and infoboxes and using them to establish notability, doesn't prevent us from reporting them AT ALL? valereee (talk) 12:22, 19 February 2019 (UTC)

     Depends how you read it I suppose, but that is certainly my interpretation of it. It would definitely disallow the numbers being mentioned in the infoxbox and lead even when they were (per secondary sources) key parts of the subject's notability and regardless of whether they were reliable or not. Thryduulf (talk) 12:58, 19 February 2019 (UTC)

9. Support: Subscriber, follower, like count isn't an indicator of notability. GN-z11 [[User talk:GN-z11|^☎
10. Support - Subscriber, follower, “like” counts are primary data. They may underlie notability for social media personalities, but (because they ARE primary data) they are not (on their own) enough to determine whether a social media personality is Notable or not. This is why we need independent secondary sources to comment upon the personality (and the numbers). As for listing the numbers in an infobox - given how frequently the numbers fluctuate, I don’t see them being particularly useful data. They will constantly be out of date. Blueboar (talk) 19:23, 15 February 2019 (UTC)
11. Support Very well worded. They don't necessarily need to be banned from the top section altogether but this is certainly not something that should even be considered when it comes to establishing notability or emphasized in a biography once that is passed. Subjects should have more interesting content about them to fill the lead with than their follower statistics. Reywas92^Talk 05:06, 16 February 2019 (UTC)
12. Support As a very primary source should not be used to establish notability. Once notability established sure may be used sparingly. Doc James (talk · contribs · email) 20:41, 16 February 2019 (UTC)
    • This would also prohibit use in situations where such numbers are the basis of notability in other sources (e.g. where a video becomes notable to reliable sources because it has a large view count.) Thryduulf (talk) 21:12, 16 February 2019 (UTC)
      • It's not our job to tell readers why The Fooland Times decided Alice B. Ceesdale was worth an article in their newspaper; trying to do so is probably OR. It's our job to scrape the article for encyclopedically relevant information about Ceesdale and cite them as the source for it. If the article was really just an "OMG, she got 42 million Likes!" fluff/puff piece without any real substance, then a) it's not much of a source for anything, and b) it's enough to describe her Youtube video or whatever as having gone viral; the specific number is meaningless, since it'll be different a day later, and even what it means in relative terms will shift over time as social-media usage patterns change. [Back in the day, I was the editor of an online newsletter with around 40K readers and that was huge, one of the most-read publications of the early public Internet. Today, that would be a joke – like, "come talk to us when that has two or three more zeros at the end, dude". Heh.]  — SMcCandlish ☏ ¢ 😼  12:03, 19 February 2019 (UTC)
        • If the mention is just a puff piece it isn't suitable for our use (for most purposes) per existing policies, but there are non-puff pieces that this policy would prevent being used with no consideration for quality. This is one of the biggest problems with this proposal it doesn't allow for any consideration of individual circumstances, context or anything that isn't a bad-faith attempt to manipulate our content. A guideline discouraging the use of stats as key information without secondary sources to explain its relevance and significance would be both unproblematic and redundant. Thryduulf (talk) 13:03, 19 February 2019 (UTC)

          It wouldn't prevent non-puff journalism from being used at all; just not used for social media statistics which will soon enough be meaningless or worse.  — SMcCandlish ☏ ¢ 😼  14:50, 12 March 2019 (UTC)

13. Support This would help two things simultaneously: the 1) "they have a lot of views, therefore they're notable!" arguments, and 2) making sure user counts, subscribers, or views can be mentioned in the article, but only if backed up by secondary sources. There's currently an ongoing argument on a web-based software platform regarding how many people actually use the site, a problem because the higher number has been discredited but proponents obviously want to use that number instead of the much lower number of daily users. While oppose !voters may be right in saying you can't use primary sourced statistics anyways, I do see a problem here since this can be ignored, and this would help fix the problem. SportingFlyer T·C 22:48, 16 February 2019 (UTC)
14. Support When we have access to good data about social media statistics from a stable third-party source then we should include this. This is defining data, much like the number of employees or revenue of an organization. I recognize that this is primary source content but it is also fundamental to understanding these channels and not something that we are likely to find in what we now define as reliable sources. There are a range of problems with including this data and I think we need to build out some policies and norms, but I support moving in this direction. Blue Rasberry (talk) 23:55, 16 February 2019 (UTC)
    • @Blueraspberry: Your rationale seems to be in contradiction to your bolded "support"? You seem to be in favour of including social media statistics (in at least some circumstances), but this proposal is about disallowing such information in all circumstances. Thryduulf (talk) 00:42, 17 February 2019 (UTC)
      • Um... no... the proposal just limits where we can mention the statistics. It does not disallow them entirely.
15. Limited Support Get rid of it in infoboxes, but if an editor thinks it's important enough that it belongs in the lead, that should be handled case-by-case valereee (talk) 13:36, 17 February 2019 (UTC)
16. Support. The social media cruft isn't really relevant. If there's coverage of a subject in reliable sources, that's what matters (both in AfD arguments and in what's important to have in an article). Primary-sourced statistics (from proprietary, commercial Web sites, no less) are prone to fakery and deserve no weight. —{{u|Goldenshimmer}} (they/their)｜😹｜✝️｜John 15:12｜☮️｜🍂｜T/C 16:06, 18 February 2019 (UTC)
17. Support for multiple reasons, including WP:NOTSPAM and does not lead to subject significance. funplussmart (talk) 21:33, 18 February 2019 (UTC)
18. Support. Aside from all of the above, there's a WP:NOT#SOAPBOX issue. Reliable sources, not fans of the subject (or even the subjects editing their own article) tell us what these stats are and and when the real world considers them important with regard to a particular subject. It is not lead-section material. If there's ever an exception, e.g. because a particular number of "likes" or whatever (new world record in 24 hours?) is itself part of the reason for notability (and RS say so, not people on the talk page), then an exception can apply per WP:IAR (aside from legal policies forced on us by the foundation, none of WP's rules are exception-free).  — SMcCandlish ☏ ¢ 😼  03:04, 19 February 2019 (UTC)
    • @SMcCandlish: if you have to bake in IAR when designing a rule then you've got the rule very, very wrong. IAR is for situations that were not anticipated by the rule or which are truly exceptional and so the rule needs to be bent. This proposal would require frequent examples of the rule not just being bent but broken to the extent of being the exact opposite. Thryduulf (talk) 10:40, 19 February 2019 (UTC)
      • @Thryduulf: I think I've been a bit misread on this. I have in mind what WP:P&G explicitly says about guidelines (i.e., this is an actual rule in policy about them): "Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply." This principle is pretty frequently cited and is a form of IAR. (And IAR itself is a policy, a rule! Heh.) I didn't mean that people need to specifically say "Per WP:IAR." Nor do I think what's being contemplated here is policy rather than guideline material, just to be clear; nit-picks like this don't rise to policy level. This would almost certainly end up in MoS, since it's about leads and infoboxes: MOS:LEAD, MOS:INFOBOX. And it thus would not actually be phrased in terms like "may not be" absolutes, but in our usual softer guideline language. I.e., your concerns that this "bans" or "prohibits" something would not actually be possible, since MoS can't actually do that, just lay out a best-practice default which is sometimes ignored when common sense tells us to ignore it on a case by case basis. That's the heart of IAR anyway, and we do it every day without actually having to cite IAR by name. It's just how guidelines work, so you can just cite the lead of WP:P&G instead of citing WP:IAR.

        Anyway, if you think that exceptions that would really be encyclopedically justifiable, and necessary for proper coverage (not just desired by fanbois trying to PR-massage their idol's article) would actually be all that frequent, then we can write a specific set of exception criteria, or include a more generalized exception statement. We do this all the time (especially in MoS). I understand your reaction to the strident tone of the draft language, but WP:Writing policy is hard, first drafts almost never get it right, wording of such a line-item in any P&G page is not set in stone, and if something is codified in too-stringent an initial form, the kinks get worked out pretty quickly with a round of revision to deal with unintended consequences.
         — SMcCandlish ☏ ¢ 😼  12:03, 19 February 2019 (UTC)

      • @Barkeep49: Please see the above, and moderate the tone of some of the wording; people are reacting negatively to its "This shall be thy Holy Law" stridency, rather than assessing the intent of it. Read around in the main MoS page, as well as MOS:INFOBOX and MOS:LEAD, to see how MoS guideline material is actually written.  — SMcCandlish ☏ ¢ 😼  12:07, 19 February 2019 (UTC)
        • (edit conflict) Yes writing policy is hard, that's why we should restrict policy to situations where it is needed (per others this is not one) and go through several drafts where problems are identified and ironed out - which has not happened here. A new rule or policy such as this attempts to be should be correct in (almost) all forseeable circumstances in which it would apply: per my and other's objections this is very much not the case. No we don't want fans attempting to use social media stats to inflate articles, but we don't need this to do that - we already have sufficient policies and guidelines around reliable sources and neutral languages, which work. Whether social media stats are or are not relevant is a matter that needs to be judged in the context of the individual article. Also, this is not just a disagreement about the stridency of it, my objections are also that it is unnecessary. Thryduulf (talk) 12:15, 19 February 2019 (UTC)
19. Support – social media are nothing compared to reliable secondary sources. If a secondary source see fits to comment on exceptional social media stats, then maybe there's something we can say, but not otherwise. Dicklyon (talk) 03:15, 19 February 2019 (UTC)
    • @Dicklyon: but this proposal would prohibit using social media stats completely, even when that is the basis for coverage in independent reliable secondary sources. If you believe there are any occasions when social media stats are relevant to notability and/or significant information about the subject then you should be opposing this proposal. Thryduulf (talk) 10:34, 19 February 2019 (UTC)

    Again... no... the proposal does not prohibit using social media statistics completely... it just prohibits them from infoboxes and the lead. We would still be able to mention them in the other sections of the article. Blueboar (talk) 11:10, 19 February 2019 (UTC)

    That's part of the problem - what you intended and what I'm reading are not the same thing, but even if it only prevents them being used in the lead or infobox it does so in all circumstances (and discourages them elsewhere) regardless of what the circumstances are - even when that is a significant part of their reliability which should be mentioned in the lead and/or infobox. What is needed (if anything is) is broad and flexible guidelines as to best practice in typical cases, not hard and fast rules that must be adhered to regardless of what the facts on the ground actually are. Thryduulf (talk) 13:07, 19 February 2019 (UTC)

    Why don't you draft an alternative and I'll see if I can support that better than this one? Dicklyon (talk) 06:00, 20 February 2019 (UTC)

    @Dicklyon: because I'm increasingly of the opinion that the only guidance that wouldn't have the same problems this proposal does would be redundant to our existing policies and guidelines (and common sense). Thryduulf (talk) 10:48, 20 February 2019 (UTC)

20. Support - no reason at all for them to be mentioned in the infobox. In the lead, I could see some very few edge-cases where, for example, PewDiePie is mentioned as the YouTuber with the most followers and there was active RS coverage of him about to lose it; or the Instagram egg with the amount of likes. The stats in this case are important to the context and are equivalent to something like the reported ratings for a TV show. Yes, these stats can be bought, but regardless for these handful of cases, this context is needed in the lead (and body) of the article. It is never needed in the infobox. --Gonnym (talk) 14:13, 19 February 2019 (UTC)
21. Support - A number of people liking something or following someone is not notability (besides some exceptions) and should not be treated as such. Reliable secondary sources should be the go-to. Kirbanzo (talk) 16:58, 19 February 2019 (UTC)
22. Support in a WP:NOTSPAM way. Common sense should be used to determine if it's useful information or just promotional. There are obvious exceptions like PewDiePie, but I think that even those cases only deserve a brief mention in the lead. Reliable sources often publish articles with headlines like "X Y passes Z million subscribers", but that is in my opinion usually only good for a mention in an article's body. A big problem is that lead sections have the strongest verifiability requirements as per MOS:LEADCITE, and ever-changing statistics are unlikely to be recorded in a reliable source forever. As subjects about which I wouldn't worry too much about promotional content are non-profits, social experiments, various curators etc. whom we wouldn't really be promoting with several statistics in an article body and up to one in the lead, of course at a specific date and cited to a reliable source. Still, infoboxes should receive minimal changes and so do articles; I can't imagine why "gained X views in the first week" or something like that would need to be constantly brought up-to-date. If it's cited to a reliable source, leave it be. If it isn't, find a source or remove it. There are inaccuracy concerns brought up by some editors, and I don't have an opinion on it. On one hand, you have plenty of reporting on these statistics and on their audits, while on the other hand, you have lengthy reports on their abuse. wumbolo ^^^ 10:00, 20 February 2019 (UTC)
    • @Wumbolo: In other words you think we should continue to do things exactly as currently and decide what is significant and what isn't on a case by case basis using a combination of common sense and reliable sources. Which is exactly the opposite of this proposal. Thryduulf (talk) 10:50, 20 February 2019 (UTC)
23. Support: Social media statistics are trivial to manipulate (See Wikipedia:Village pump (policy)#Please do the following web searches), the only limit to how high your numbers can go is your budget, and there is no way to detect the fraud. You can't say that about sports scores, financial reporting, or election results. Those all make an good-faith effort to give you real numbers instead of letting anyone with a credit card choose whatever numbers they want Wikipedia to report. And there is no "case-by-case basis" decision to be made; social media statistics are trivial to manipulate in all cases, without exception. No known social media platform does any sort of authentication other than asking you to reply using a free throw-away email account. --Guy Macon (talk) 12:57, 20 February 2019 (UTC)

    Quora and Google already have a system in place, although it's not perfect. Twitter and Instagram are getting close. wumbolo ^^^ 19:15, 20 February 2019 (UTC)

    I don't think Google has any social media statistics, or anything resembling "likes" "views" "upvotes" etc. Please correct me if I am wrong. Does Quora have anything like that, and can someone post social media statistics from Quora? If so, then it would appear that Quora is an exception to my "No known social media platform does any sort of authentication..." statement above, and I owe you a big thanks for correcting my error. --Guy Macon (talk) 19:40, 20 February 2019 (UTC).

24. Support Anything that denies fans their joy pleases me. Chris Troutman (talk) 23:38, 20 February 2019 (UTC)
25. Support Everyone above said it well. Subscriber and follower count should be a minor detail, not an establishment of notability here in a encyclopedia. –eggofreason^talk 15:47, 21 February 2019 (UTC)
26. Support I'm not so happy with the reliability of reliable sources any more but so far that's all we got. --tickle me 03:01, 25 February 2019 (UTC)
27. Support. Absolutely. Softlavender (talk) 03:25, 25 February 2019 (UTC)
28. Support. Yes, if they are to be made notable, it is because they have been written about, also, bots. take a look at this if one of the most Subscribed Channels lost that many, what is to say that an account may really have only like 2k subs instead of 5K? LakesideMiners^{My Talk Page} 17:51, 25 February 2019 (UTC)
29. Support - Others have said it sufficiently above, and many of us have said it multiple times in the past. Including this kind of material is messy, and we too often inflate their importance (and their connection to notability). — Rhododendrites ^talk \\ 05:02, 27 February 2019 (UTC)
30. Support – social media stats are easily gamed, and not to be used as an indicator of notability. We base our content decisions on reliable sources, not statistics. Bradv🍁 14:13, 27 February 2019 (UTC)
31. Support These are difficult to keep current, very susceptible to being gamed and not particularly useful to readers (if the information is relevant, it should be put into context in the article itself, following the lead of how reliable sources contextualize it). Just a Rube (talk) 14:40, 27 February 2019 (UTC)
32. Support. I agree that this is trivia of interest mostly to marketers. We can discuss it in the body of the article when reliable sources cover it. NinjaRobotPirate (talk) 04:35, 28 February 2019 (UTC)
33. Finally there is a proposal about this frequent issue. ~ ToBeFree (talk) 13:01, 12 March 2019 (UTC)

Oppose (social media statistics)

1. I'd learn toward assuming subscriber and view counts are not largely manipulated, unless there's some specific reason to think so, in any given case. Benjamin (talk) 00:27, 15 February 2019 (UTC)
2. Oppose based on wording. These should be handled on a case-by-case basis, with well sourced numbers being included where reasonable. The wording used is too restrictive, IMO. Nihlus 02:44, 15 February 2019 (UTC)
3. Oppose based on wording and Nihlus. These metrics constitute an important part of the notability of many articles that use them, and properly sourced they deserve mention for that reason. --Tom (LT) (talk) 09:03, 15 February 2019 (UTC)
4. Oppose per Nihlus und Tom. I also don't see why a blanket ban on use in infoboxes is required even if the numbers are verifiable. Since these are statistics that are oftentimes relevant to readers, they should be quickly glanceable from the infobox (similar to company articles having information of employees and earnings in the infobox). For example, PewDiePie (a good article!) demonstrates how the number of subscribers can be very important to be mentioned in the lead and infobox since that is one of the major reasons why he receives all that significant coverage in reliable sources. Regards SoWhy 12:09, 15 February 2019 (UTC)

   Also, that proposal would force editors to violate MOS:LEAD on a regular basis because the lead is supposed to "summarize the body of the article with appropriate weight" and this includes such statistics in many cases. Regards SoWhy 12:52, 17 February 2019 (UTC)

5. Oppose. Establishing an overarching guideline or policy for social media statistics if a form of instruction creep. Their use in various articles should be decided on a case-by-case basis, taking into account existing rules. Calidum 19:13, 15 February 2019 (UTC)
6. Oppose per SoWhy, Tom, and Nihlus. While we shouldn't have an SNG that says "people with X Twitter followers are automatically considered notable", we shouldn't tell editors where to mention the number of followers in case it is worth mentioning. —Kusma (t·c) 20:47, 15 February 2019 (UTC)
7. Oppose Unnecessary. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:22, 15 February 2019 (UTC)
8. Oppose. I support the principle behind this proposal, but I don't believe this change is necessary. As primary data, social media statistics already cannot be used on their own to establish notability; notability must be established with reliable sources. And if reliable sources determine that a subject is notable in part because of their social media presence, that information should probably be part of the encyclopedia, so long as the date the information was retrieved is tagged. Novusuna ^talk 22:08, 15 February 2019 (UTC)
9. Oppose; the proposal is flawed. While notability something something reliable secondary sources, there is no need for a ban specifically targeting data by social media companies. In addition to the points raised by others about the statistics' importance, a large amount of useful data on other topics (e.g. TV viewership) is also basically unverifiable for practical purposes, and the manipulation of data by third parties does not render the data useless, particularly for services which already actively counteract data manipulation. Jc86035 (talk) 06:55, 16 February 2019 (UTC)
10. Oppose. This absolutely needs to be handled on a case-by-case basis. Sometimes it's significant information, other times it's meaningless trivia. Sometimes they should be included in an infobox, other times they shouldn't. Thryduulf (talk) 14:23, 16 February 2019 (UTC)
11. Oppose They should rarelybe in aninfoboxx or lede, but there willbe occassionalarticles where it's the key information. Foor notability , we should use and evaluate whatever is available. DGG ( talk ) 00:01, 17 February 2019 (UTC)
12. Partial oppose I have no problem with some of their use in infoboxes or in lead sections, however I agree that explicit language needs to say that they have no bearing on notability for Wikipedia purposes. Some social media numbers, for example YouTube subscriber and viewership numbers, are equivalent to, say, album sales or Neilson Ratings in other media forms, and are important metrics. Some social media numbers aren't that big of a deal (Facebook friends, for example). I could support a statement that only makes explicit that these numbers have no bearing on notability, AND I could support a guideline that explains where and why some social media numbers are good, and others are not, but I can't support this statement which conflates several issues, and lacks the nuance necessary to handle the issues around social media stats. --Jayron32 13:23, 19 February 2019 (UTC)
13. Oppose per WP:CREEP and WP:NOTLAW. Statistics of this sort are naturally suspect and so need good evidence -- the size of a crowd, the number of sales, the volume of a print run -- but we should not discriminate against modern technologies just because they are new. Andrew D. (talk) 10:59, 21 February 2019 (UTC)
14. Oppose not so much overall. I fully agree that social media stats originating from just checking the person's channel/page/etc. is the type of thing to avoid in infoboxes or ledes. On the other hand, there are enough cases of third-party RS sources that comment on subscriber counts (eg I know there exists some for PewDiePie but that was from a few years ago) that is core information about why we have an article on that person that should be in the lede, but based on the point in time given by the RS. This also speaks to the notabilty issue - agree that only on simply viewer count is nowhere near sufficient (the GNG already dismisses popularity as a notability reason), but that when you get this type of coverage in third-party, you are getting the right sources even though that may be solely based on viewer count. In other words, the proposal has the right ideas in mind but throws out the baby with the bathwater. --Masem (t) 14:47, 21 February 2019 (UTC)

    To add, I fully support a ban on these types of stats in infoboxes until we have a reliable third-party tracking source similar to Neilsen for television programs or Alexa Internet for web page rankings or the like. Such fields should not be in any related infobox as they will draw in "bad" data in the absence of a reliable source. But the lede inclusion is different. --Masem (t) 14:56, 21 February 2019 (UTC)

15. Oppose as it is one of the main claims of significance of a youtuber and removing that information from the easy to find infobox will only frustrate and annoy the reader who expects to find the germane information in a wikipedia article. It's similar to record sales or film box office takings, all statistics are vulnerable to manipulation but YouTube and other social media concerns are currently reforming their processes with the intention of making these figures more reliable and trustworthy. Also, as these statistics are routinely reported in many reliable sources that should be the determing factor that they have a place in wikipedia with perhaps a caveat of including a link to an information page or article about the reliability of such statistics, thanks Atlantic306 (talk) 17:27, 23 February 2019 (UTC)
16. Oppose As mentioned above, this rule would force us to violate MOS:LEAD whenever the social-media standing of an individual is an important aspect of their life or career. XOR'easter (talk) 18:45, 26 February 2019 (UTC)

    Also, as others have pointed out, the proposal conflates distinct issues. There's the question of what can justify the existence of an article (notability), versus what belongs in an article (comprehensiveness, verifiability, due weight), versus what belongs in which part of an article (layout and style). Lumping all these together is counterproductive. In addition, we need to distinguish primary from secondary sources. If I look up a YouTube video and see its current number of up-votes, or if I look up a scientific journal article and the website tells me its altmetric scores, then that's a primary source for the figure in question. Maybe a big number means something, and maybe it doesn't; making a judgment call there would likely amount to Original Research. But if Science or Nature report on a journal article getting the most hashtag coverage of the year, then someone else has made the judgment call about that being important. XOR'easter (talk) 16:56, 28 February 2019 (UTC)

17. Oppose as worded because it combines too much: notability (new stand-alone article) with inclusion (in existing article), infoboxes with leads, and all social media statistics in one category. These are separate issues, and I can see a lot of case-by-case variation. I feel our existing policies on verifiability and notability are sufficient to guide editors for those case-by-case decisions; I'm not seeing the benefit of having a new overarching rule, and I'm afraid this rule, as currently worded, would constrain editors' decisions rather than help them make those decisions. For example: There are cases where people or videos or images are notable because of how many "views" or whatever they've gotten, and in those cases, it would be strange not to include that information in the lead of those articles. We already have policies not to include content that's not reliably sourced and this proposal doesn't address what is and what isn't an RS for social media stats. "Sparingly" is too open to interpretation, and maybe too permissive (why would we state the number of views more than once? ...and why would we need a rule about how often to say something anyway? NOTBURO.). So I wouldn't be in favor of making this proposed language into a new policy. That said, I wouldn't necessarily be opposed to changes to existing policies/guidelines relating to social media, e.g., for notability, in infoboxes, etc. I could see changes to WP:N, WP:RS, WP:MOS, and I'm not sure where the rules are for infoboxes. I also wouldn't be opposed to like a social media guideline that essentially interpreted our policies as they apply to social media, but it would need to be a lot longer than a few sentences to be helpful. Leviv ich 00:55, 28 February 2019 (UTC)
18. Oppose as worded. Usually they do not show notability , usually they do not belong in infoboxes or ledes. If they are high enough, and reliable sourced, they do contribute to showing notability . Such cases are rare, but they do exist. A blanket ban on anything is rarely a good idea. WP should be made not by a bot-like process, but by humans who think. And, if they are reported by a selective RS, that report makes them non-primary. DGG ( talk ) 19:46, 28 February 2019 (UTC)

    DGG I would suggest, and indeed am suggesting, that even in exceptional circumstances, given the lack of any sort of SNG, that it's going to be the coverage by RS that makes a social media influencer notable not the raw (inherently unreliable) numbers. So the numbers don't help establish notability and instead we should, as we do as good encyclopedia writers, take our cue from RS about how much, if any, overall coverage to give them. Best, Barkeep49 (talk) 04:10, 1 March 2019 (UTC)

19. Oppose per XOR'easter above. Sometimes the number of likes/views/etc. is important to an article - Gangnam Style comes to mind, see the first lead paragraph. I agree that a high number can't give notability on its own and that in many cases it would be inappropriate to mention in an infobox or lead, but this proposal goes a bit too far. ansh666 01:42, 4 March 2019 (UTC)
20. Oppose. While there's good reasons not to put too much emphasis on these statistics for notability, a blanket ban on their use in the lede or infobox is an overreach, and restricting their use in the body to the bare minimum is ridiculous. Often for the subjects of these articles, these statistics are a good rough estimate of their relative importance as a social media personality, and should be included, since this is helpful to the reader. And in certain cases, social media statistics are central to the subject's importance and should have more than sparing coverage in the body and should be included in the lede. For example, articles such as Pewdiepie, Despacito, Gangnam Style should absolutely mention statistics more like being the most-subscribed YouTuber, most viewed YouTube video, first YouTube video to 1 billion views, and this proposal as written would disallow mention of that in the lede or body beyond very short coverage. ---- Patar knight - ^chat/_{contributions} 17:18, 4 March 2019 (UTC)
21. Oppose. There are very occasional subjects that receive significant coverage in independent secondary sources precisely because of their social media statistics. R2 (bleep) 20:13, 8 March 2019 (UTC)

Neutral (social media statistics)

1. Neutral should be on a case by case basis as they may be cases where the stats are useful for example in the PewDiePie vs T-Series article where 2 youtube channels are competing to be number 1 in subscribers. However I believe in the majority of cases the stats should not be used in articles Abote2 (talk) 10:56, 15 February 2019 (UTC)
2. Neutral If we had stable access to some third party database which maintained this kind of information then I would support us including it in infoboxes. I agree that social media statistics, like number of subscribers, is defining information for people, organizations, and publications which have social media channels as their primary venues. The problematic point of this to me is verifying that numbers are correct. If a citation claims a social media count in a point in time, then so far as I know, we have no good way of verifying that count. Blue Rasberry (talk) 22:54, 15 February 2019 (UTC)

   @Bluerasberry: For most sites I would think the Internet Archive would be good enough, mainly because of the difficulty which would be involved in falsifying data. I used it to (deliberately) collect the data in the graph at List of most-disliked YouTube videos, for example. Jc86035 (talk) 19:44, 16 February 2019 (UTC)

   @Jc86035: I did not realize that Internet Archive repeatedly archived user responses to YouTube videos. Wow, that does make for stable information. I am going to change to support. Blue Rasberry (talk) 23:52, 16 February 2019 (UTC)

   @Bluerasberry: Wait, you support including the information in infoboxes, but you've changed your !vote to support a proposal that would ban including this information in infoboxes? Novusuna ^talk 00:02, 17 February 2019 (UTC)

Discussion (social media statistics)

• As a bit of a tech luddite, I'd welcome a broader discussion as to how these stats relate (or not) to notability. Such articles are often nominated for speedy deletion under the A7 criterion, despite ostensibly containing claims to notability. Espresso Addict (talk) 01:45, 15 February 2019 (UTC)
• I am leaning oppose but would appreciate hearing editors opinions on:

1. Our articles are accurate even when the numbers aren't. If a Twitter account has a million followers, and we say "According to Twitter, the account has a million followers", we're not saying a million people follow the account; we're saying Twitter says a million people follow the account. It's verifiably true that Twitter made the statement, even if the statement is wrong.
2. It's relative. Whether PewDiePie or T-Series is "winning" is based solely on what YouTube says their subscriber count is. It doesn't matter if it's accurate, inflated, not inflated, etc., because, for example, if it is inflated, presumably they're both inflating it, and what matters is who was more successful at inflating it. If cheating is allowed in a race, and both runners cheat and one of them wins, they're still the winner, even though they cheated, and the article on them should still say they won the race, and what their time was, even if it was manipulated by cheating.
3. The world believes it. RSes report on SM stats. Shouldn't that be the end of the discussion? If we substitute our judgment for RSes, isn't that WP:OR?
4. When YouTube reports data about their website (which is what social media stats are), isn't that something we accept as a reliable source per WP:ABOUTSELF?
5. Corporate profits are overstated and manipulated but we still provide them (because RSes report them); so are Nielsen television ratings; professional athletes sometimes cheat, we still list their stats even though we know them to be manipulated. All sorts of statistics are manipulated; the world is an inaccurate place; why are social media stats special? Leviv ich 01:51, 15 February 2019 (UTC)

On your last point, egregious manipulation of corporate profits is illegal, the law is actually enforced and every now and then someone gets busted for it. Executives have been sent to prison for securities fraud, but padding social media stats has very little consequence. MER-C 12:10, 15 February 2019 (UTC)

• @Nihlus: This proposal leaves open, on a case by case basis, the inclusion of what you're asking for ("well sourced numbers"). It does give a bit more structure to what well sourced is (sigcov in independent RS) but this leaves lots of room for editors to find the right balance. For instance under this standard I would expect that PewDiePie would have numbers covered in some depth because there is plenty of sourcing that meets this standard for him. Best wishes, Barkeep49 (talk)

• Can we please split the proposed language? It combines two completely different things: a) whether statistics etc. establish notability and b) how such information may be used. Users currently have no way to support a) without supporting b) and vice versa. Regards SoWhy 13:18, 15 February 2019 (UTC)

  Agree this would be helpful; my votes on a) and b) would be different. Leviv ich 21:41, 15 February 2019 (UTC)

• Why is this needed? Surely our current policy/guidelines lead to pretty much the same conclusion? Phil Bridger (talk) 21:37, 16 February 2019 (UTC)
  • In such circumstances its usually because the existing policies/guidelines sometimes result in consensuses a few people don't like, so they feel the need to introduce rules that don't allow for things like exceptions, common sense, etc. Thryduulf (talk) 23:08, 16 February 2019 (UTC)
    • I still think I'm missing something here. Can someone give an example where this proposal would lead to a different outcome from current policies and guidelines? Was this prompted by any particular incident? Phil Bridger (talk) 18:27, 17 February 2019 (UTC)
      • Ok, I think I've found what prompted this: Talk:Mark Dice. We all (or at least those who have been editing here for a long time) know that Jimmy Wales likes to suck up to people who he imagines to be rich and powerful, and to support their efforts to make promotional edits about themselves if they contact him directly. That's no reason for anyone else to take any notice of what he says, and certainly no reason to change policy or guidelines. Phil Bridger (talk) 20:18, 18 February 2019 (UTC)

    Most of this is an outgrowth of current practice in some areas - AfC for instance - but not others, i.e. the pages of many YouTubers, and the results of the never endng stream of scandals around maniupulation. Literally as I was preparing this RfC the latest issue with Instagram broke. I'm not inventing a problem out of nowhere. Before going down this route I tried a series of edits and faced several editors who told me "reverting if you want this get an RfC." Since doing this RfC the rest of my edits were reverted in bulk though it's not clear if it's as a result of this or not as that editor has not commented here.

    Thryduulf I do regret the style guidance above. That was overly prescriptive and gets in the way of the larger point. Best wishes, Barkeep49 (talk) 04:45, 19 February 2019 (UTC)

• YouTube regularly audits views and subscribers. [3] [4] [5] [6] wumbolo ^^^ 20:41, 18 February 2019 (UTC)

• That's just whistling in the wind. Those sources by no means counter the overwhelming evidence to the contrary that such statistics are unreliable. I could easily sign up with many different accounts from many different locations and "like" people on social media, and nobody would know that I am the same person. Phil Bridger (talk) 21:31, 18 February 2019 (UTC)

Please do the following web searches

Do a web search on "buy twitter followers", "buy facebook followers", "buy instagram followers", "buy youtube subscribers", "buy reddit upvotes", "buy flickr followers", "buy pinterest followers" "buy tumblr followers"...

I'm just saying. --Guy Macon (talk) 14:32, 17 February 2019 (UTC)

We should certainly treat such statistics with a large bucketful of salt, but I don't see why we need a new guideline to do so. We judge the reliability of all sorts of sources for all statements in all articles all the time, so shouldn't we just do the same for these statistics produced by social media sites? They can clearly be gamed, so shouldn't be treated as reliable, especially when they are claimed to boost someone's notability. Phil Bridger (talk) 18:27, 17 February 2019 (UTC)

@Guy Macon: How is that different from corporate profits or corporations' net worth? Those are manipulated routinely, reported in RSes routinely, and included in our infoboxes routinely. We report the finishing times of Lance Armstrong and the batting average of Barry Bonds even though we know those statistics were obtained by cheating. I mean, lots of information is subject to manipulation or is not objectively true and accurate, but we still include it if the RSes include it. Why should SM be any different? (This applies to including the information in the article, not to using the information for establishing notability, which is a separate issue.) Leviv ich 19:43, 17 February 2019 (UTC)

A rule would be helpful since a lot of the time the RS component gets ignored, at least from my limited experience editing in the area. SportingFlyer T·C 19:45, 17 February 2019 (UTC)

If the current rules get ignored then that's the problem we should address, rather than introduce a new rule that will also get ignored. Phil Bridger (talk) 21:27, 17 February 2019 (UTC)

User:Levivich asks "How is that different from corporate profits or corporations' net worth? Those are manipulated routinely, reported in RSes routinely, and included in our infoboxes routinely. We report the finishing times of Lance Armstrong and the batting average of Barry Bonds even though we know those statistics were obtained by cheating." Let's start with Lance Armstrong and Barry Bonds. Lance actually rode that fast and Barry actually hit those balls. If the number of times Barry Bond hit the ball was something that anybody with enough money could undetectably alter, we would treat reports of his batting average as being unreliable.

• those things have ALWAYS happened. See Payola. We still use metrics like RIAA certifications and Nielsen Ratings and the like, even though it has happened before (and probably still happens to an extent) that the metrics can be gamed. YouTube subscriber numbers are still used by industry sources as a metric. --Jayron32 17:30, 19 February 2019 (UTC)

• The difference between old-fashioned Payola and the manipulation of social media statistics is that the old way was difficult and expensive to implement, but social media statistics can be manipulated very easily and very little cost. After all, there's a limit to the number of times a record (am I showing my age by using that word?) can be played on the radio or bought in the right shop. I don't want to go too far into WP:BEANS territory, but I don't think I'm giving away any great secrets by saying that it's possible to write a script to create any number different user ids on a social media site and to like or download or whatever is needed any number of times. This is a big step change from Payola methods, which now seem rather quaint and innocent. Phil Bridger (talk) 19:29, 19 February 2019 (UTC)

As for corporate profits or corporations' net worth, as Business Insider says, "An analysis of results from 500 major companies by The Associated Press, based on data provided by S&P Capital IQ, a research firm, found that the gap between the "adjusted" profits that analysts cite and bottom-line earnings figures that companies are legally obliged to report, or net income, has widened dramatically over the past five years."[7] The key point here is that the Securities and Exchange Commission exists and will put you in jail if they catch you reporting fake financials of the official forms. Also, the auditor's report, published in the annual report in conjunction with the financial statements, gives us an independatt evaluation on whether a company's financial statements comply with generally accepted accounting principles. If a company could simply get on the net and buy fake numbers for profit or revenue, we would not consider those numbers to be reliable.

Please don't assume that just because I say that the numbers for social media likes/followers/etc. are trivial to fake that I am saying that we need a new rule. That is an entirely different question and hinges on whether our existing rules are adequate. But the fact remains that social media statistics are trivial to manipulate, the only limit to how high your numbers go is your budget, and there is no way to detect the fraud. You can't say that about sports scores, financial reporting, or election results. Those examples all at least attempt to give you real numbers instead of fake numbers. --Guy Macon (talk) 21:01, 17 February 2019 (UTC)

Separating infobox inclusion from lead inclusion

I think it would be helpful to break this into two separate questions...

1. Under what circumstances should the statistics be included in infoboxes?
2. Under what circumstances should the statistics be mentioned in the lead?

Personally, I would have different answers to each question - Much more inclined to allow mentions in leads, and much less so when it comes to infoboxes. Please discuss. Blueboar (talk) 13:28, 19 February 2019 (UTC)

• The only possible answer to both is "when they are verifiable and there is a consensus among contributors to the article that they should be included in the infobox/lead". There are far too many variables to get more specific than that for such high level questions. Thryduulf (talk) 13:39, 19 February 2019 (UTC)

  Thryduulf, what is your definition of verifiable as it applies to social media statistics? valereee (talk) 13:55, 19 February 2019 (UTC)

  Well that depends on the statistic, but primary sources will be fine for verification in most cases - (e.g. [8] verifies that Cyndi Lauper's version of Girls Just Want To Have Fun had 708 million views as of 16 February 2019), and reliable source reports are good too - e.g. [9] supports the statement that Ellen DeGeneres' tweet was retweeted more than 2 millions times by the end of the night on which it was taken. $Random_celebrity reported in a reliable source as claiming that they have more than a million followers on Twitter does not count as verification of the figure (although it obviously verifies the claim, but such claims shouldn't be in the infobox and are unlikely going to be appropriate in the lead, although it's possible). "Social media" is a very broad term and there are almost an infinite number of stats that can be derived from it - YouTube (displayed) view counts are prominent and easy to verify, but something like the number of people who have seen a person's posts on facebook is equally a social media statistic but much harder to verify (if it is even possible). Thryduulf (talk) 14:24, 19 February 2019 (UTC)

• No information should be listed in the infobox that isn't already in the body of the article. Also, no information in the lead section should not already be in the body of the article. Basically, I tend to take the general idea that it goes body-->lead-->infobox, though not strictly speaking, because there will be some information appropriate for the infobox that might not be mentioned in the lead, and vice-versa, but in general, the lead is a text summary of the body of the article, and the infobox is a data summary of the body of the article. There should (almost) never be information in either place that wasn't already explained in more detail in the body of the article. With regard to social media statistics, it really depends on context, and I am mostly with Thryduulf on this: I can see where some statistics, like YouTube views or channel subscriptions, are metrics that are akin to RIAA certifications or Nielsen SoundScan sales, and as such, are probably useful to include. For media that exists only on YouTube, insofar as it may be notable for a Wikipedia article, metrics regarding consumption of that media are useful to know. For things like "Facebook friends" or the like, I'm less inclined to find it universally useful as I would YouTube subscribers (for example, nearly all articles on music albums include data on album sales, or movies on ticket sales), but I can't say we should ban the statistic in all cases. There may be times when, in the context of an article, it bears mentioning, and even mentioning in the lead. My own lack of imagination doesn't mean I can say I would ban it from the lead, per se. However, YouTube channel subscribership does seem like the kind of data that would regularly appear in leads and/or infoboxes. Regarding reliable sources, I don't know that YouTube algorithms are unreliable, I would trust their own statements as reliable sources for their own viewership numbers. While it has been mentioned that those numbers can be faked, that's true, but it's also true for every metric of media consumption. See Payola for one famous example; when radio airplay is used as a metric, record companies bribe radio programming directors to play the song more. And so on. Reliable sources at large still report such media consumption statistics, and we should to. --Jayron32 17:42, 19 February 2019 (UTC)

Jayron makes some valid points... however, not all information that is mentioned in the body of an article deserves to be included (summarized) in the lead or highlighted in an infobox. We do use judgement when summarizing. So, the questions are: 1) Under what circumstances are viewer statistics important enough to be a) highlighted in an infobox, or b) summarized in the lead. (Are there circumstances where we should do one, but not the other?) And 2) Under what circumstances are the stats NOT important enough to be included? Blueboar (talk) 19:01, 19 February 2019 (UTC)

Well, of course. The word "summarize" has meaning, and its actual meaning is why I chose it. I hope I don't have to define every word I use, because that would get tiresome. We shouldn't be using an axe to do editing that requires a scalpel. We should decide when we should usually include such statistics, when we should usually exclude them, of course noting that there will still be times when we include something that isn't in our guidelines on such usage. I would say that metrics on consumption of social media, which is analogous to similar metrics from pre-Internet media should be used in similar ways; the subscription data for YouTube channels is analogous to the sales numbers of books. The viewership numbers of a specific video is similar in many ways to the Neilson ratings of TV shows. That is, if data is relevant to a TV show, it is relevant to a YouTube video, since they form a similar role in the modern media landscape. --Jayron32 19:21, 19 February 2019 (UTC)

That’s fine as theory, but it does not address the questions I have asked: Under what circumstances should we a) mention in the lead, b) include in infobox? Under what circumstances should we NOT a) mention in the lead, and b) include in infobox? Blueboar (talk)|

The questions are not answerable at such a high level - that's the point Jayron and I are making. The answer for a video will be different to the answer for a politician from a YouTuber, a YouTube channel, a person primarily known for twitter, and the developer of a social media platform will all be different again. List of most-retweeted tweets correctly includes a social media statistic in the lead (it doesn't have an infobox), T-Series (company) includes subscriber and video view counts in both infobox and lead (I think correctly). Tom Scott (entertainer) does include them but Ed Sheeran doesn't despite both having very a strong social media presence. Thryduulf (talk) 22:28, 19 February 2019 (UTC)

Thryduulf hits the point on the head, though I will say I did address your questions: You asked "Under what circumstances should we (include social media data)", and my response was essentially "when the metrics serve an equivalent role to analogous metrics in other forms of media". I thought that was fairly clear. I would also add "when it makes sense in the context of a specific article." and "when the metric itself is the subject of mainstream coverage of a topic." That seems to capture when it is reasonable to include social media data. Also, regarding when to include the data in the lead or infobox, I also answered that clearly. As I said earlier, "No information should be listed in the infobox that isn't already in the body of the article. Also, no information in the lead section should not already be in the body of the article." So, it would need to already be discussed in the body. In summation of what I had already said, we should include information in the lead and/or infobox 1) for information which is analogous to metrics used in non-social-media like TV, Radio, Books, Movies, etc. and 2) When it has already been discussed in the body of the article. When we should not include it is when it doesn't meet those conditions, allowing for WP:IAR-exceptions and articles where context determines that the data is a significant portion of the narrative. --Jayron32 14:24, 20 February 2019 (UTC)

head |========> point

While you hit the wrong end of the metaphorical nail, which I attempted to crudely illustrate [above], I completely agree with your approach to this; that is the right way round :) I think of best practice as building the content from the base up, not plugging in data and scrabbling around to back that if challenged. A well written lead leads to the relevant content below and shows the infobox for what it is: merely redundant or contrary data vying to replace the content, information with context and citations in sentences. Any contested field "Number of friends = " obviously can only be provided with context, wikidata is the place for labelled data fields. Pretty obviously I dislike infoboxes altogether, so advocate tight constraint on their use and misuse, and have few friends if this is what I am worrying about. cygnis insignis 14:35, 21 February 2019 (UTC)

I tend to write articles the other way around: I start with the body of the article, where I have already written the necessary details and provided references and context for all of it, and THEN I write a summary of the body as the lead. It seems odd to me that one would start with the summary. What is one summarizing? --Jayron32 16:24, 21 February 2019 (UTC)

As an aside, some people like to write an outline of what they plan to write, and then fill out the details. Of course there can be some back-and-forth between the two. isaacl (talk) 21:05, 21 February 2019 (UTC)

I apologize if I repeat a point already made as I have been busy and so I admittedly skim read a lot of this discussion, but we're not and in a place where the types of statistics are as reliable as non-social media. If that happens, I would be all about their widerspread use. But that's not the reality right now and if it ever becomes that reality we can change our practices, as a lagging indicator to reflect that changed reality. The reality also is that while the numbers themselves aren't currently reliable they do have some importance, which is why there is the carve out for discussion by RS, and, importantly, the removal of them are resisted by some number of editors meaning community consensus is important. Best wishes, Barkeep49 (talk) 16:16, 22 February 2019 (UTC)

Notifications

I have left notifications about this discussion at Wikipedia talk:WikiProject YouTube, Wikipedia talk:WikiProject Internet culture, Wikipedia talk:WikiProject Biography/Arts and entertainment and Wikipedia talk:WikiProject Blogging (chosen as these projects tag articles about Twitter, Facebook, YouTube and three YouTubers I follow). Thryduulf (talk) 14:22, 20 February 2019 (UTC)

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

Citing an encyclopedia

Hello - I'd like to hear some thoughts on an issue I've noticed with the references at Septuagint - an article rated vital level 4 in Arts, and top or high importance for 5 different Wikiprojects. The issue is that a large part of the article relies on citations from a single source, and (poorly formatted in that article) this source appears to be an article that appeared in an encyclopedia in 1906.

It concerns me because I have seen other articles using these statements - apparently cross-referencing from the WP article, and yet I can't really see the justification of such heavy reliance on a single source, in particular one from so long ago in another encyclopedia. I know we value secondary sources, but this is a bit ridiculous isn't it?

Any thoughts? JMWt (talk) 15:15, 24 February 2019 (UTC)

Avoiding any specifics about this article, which belong in the discussion that you started on the talk page, I would think that there must be better sources than one published in 1906 in any field, including bible studies, that has moved on significantly since that time. We should reflect more recent scholarship about such subjects. Phil Bridger (talk) 15:53, 24 February 2019 (UTC)

Rangeblocks

I've written User:Bri/Misapplication of blocking and would like to start discussion around excessive rangeblocks especially of educational networks and other resources available to a wide swath of users. Bottom line up front: Is there a policy or even guidance on how admins are to weigh the impact on the project of blocks affecting large numbers of contributors? Under the current system blocks appear to be ad-hoc, sometimes punitive, applied for arbitrary time periods, and under the radar unless one is skilled in sussing out edit summaries and technical logs. In addition long-lived hard blocks make it impossible for well-intentioned users to even request an account. This is contrary to policy. ☆ Bri (talk) 18:21, 24 February 2019 (UTC)

Bri, I'm not certain "no apparent reason" is accurate when looking at that database report. For an example, in the report, 159.65.0.0/16 shows no reason given, but there is clearly a reason - "{{colocationwebhost}}: <!-- DigitalOcean -->". There are many other instances of this - it looks like there may be an issue with that database report. This quarry should have the missing data filled in. SQL^{Query me!} 21:57, 24 February 2019 (UTC)

I have raised the issue (and provided a fix) regarding the errors in the database report at Wikipedia_talk:Database_reports/Range_blocks/Configuration. As to some very specific examples you've listed - we should probably notify those editors: Materialscientist (regarding [10]), and Gilliam (regarding [11]). As far as indef'ed ranges - specifically those set by Ryulong, those are webhosts. They shouldn't be editing - but I am of the opinion that they probably shouldn't be blocked indef. IPs change hands - we should be re-checking those periodically. SQL^{Query me!} 22:14, 24 February 2019 (UTC)

FYI, SQL, last I heard, Materialscientist has notifications disabled. —DoRD (talk)​ 11:16, 26 February 2019 (UTC)

DoRD, Thanks, left a TP message. SQL^{Query me!} 04:35, 27 February 2019 (UTC)

• Is there any evidence of a problem? Is there an example of an IP block that was removed and where some of the IPs went on to do good work? That is, work that outweighed any vandalism from the range? Total freedom would be wonderful but in reality it is not satisfactory to rely on someone else to do the cleanup from open proxies and vandalism-only IPs. Such cleanup is soul destroying and burns out the few good editors who do it. They need support from the community, not hurdles. Johnuniq (talk) 22:33, 24 February 2019 (UTC)

I prepared a long answer to this that I think I'll save for later if someone else wants to talk about what excessive means. WP:IPBLENGTH already answers this is a plain-English way. Instead here's a response to your question about vandalism-only IPs. Basically I challenge that there is such a thing as a vandalism-only educational range at all. I don't buy the argument that all these libraries and school districts on the blocklist are full of nothing but vandals. What is the human capital we're turning away from the project by blocking them? SQL linked above to two three year blocks of two states' education networks, account creation blocked! There most definitely is a cost imposed on us by blocks. The reckoning of the cost should be public and demonstrable, not just some hand-wavey clairvoyance about negativity of future contributions from a range. It seems to come close to an elitist and hostile attitude to a whole population of people among whom are some bad actors. ☆ Bri (talk) 04:03, 25 February 2019 (UTC)

There is no proof that keeping a long block of an IP range is necessary, but you have just demonstrated that there is no evidence that unblocking is ever helpful. Johnuniq (talk) 22:53, 25 February 2019 (UTC)

I have several times asked about this while I was on arb com. The general line of response from arbs and other functionaries was the the need to block vandals was so important that the minor difficulty of asking people to make accounts outside the institution was trivial. I disagreed rather completely, but the reception to my questions was so negative, that I did not pursue it further. It was my impression that most of my colleagues on the committee had no conception and nor realization at all that the survival of wikipedia requires the continual recruitment of new editors, and anything that has the effect of discouraging this harms the encyclopedia. They did not realize the difficulty for many people in the world of editing from anywhere except their schools and libraries. They did not realize that we need to take advantage of every opportunity someone has to contribute, because if they run into difficulties initially, very few will keep trying. I attribute this total misunderstanding of priorities to be the result of the focus of almost everybody who would want to be a functionary on dealing with disruption, more than on editing. They see the problems from the small part of the encyclopedia where they work, but not those from the main function, content building.

I make the following proposal as first step, what I consider a very modest proposal: a range block for more than 4 months, that involves a school or library requires clear consensus . I consider this minimal, but it would at least require periodic discussion. Those who would be involved in such discussions are mainly involved with vandalism fighting, not editing, and 4 months (the length of a school term) is a very long time--but I can see a one person persisting that longer, but think it would be very rare for it to be longer. We have edit filters to deal with such problems. Assuming that the WP does not bring itself into total disrepute after a year of a policy like this, I'll suggest changing it to 1 month. DGG ( talk ) 19:53, 25 February 2019 (UTC)

Those are good points but keeping editors is also necessary! A new user can be enthusiastic for a month then run into persistent silliness from a range of IPs. It does not help to tell a new user that there is no problem, all they have to do is AGF and take an hour to explain procedures to each new IP and be sure they don't edit war. Anyone, new or experienced, can be burnt out by unrelenting silliness. Johnuniq (talk) 22:53, 25 February 2019 (UTC)

Those aren't mutually exclusive goals. From a purely technical perspective, there is no good reason to indef IPs, because these may be re-assigned by ISPs without warning and without notice. Blocks/Unblocks can and should be carried out by adminbot; for example, ProcseeBot tirelessly identifies and blocks open proxies. -FASTILY 02:48, 27 February 2019 (UTC)

Fastily, I've been considering doing this for a while - an adminbot that double-checks aws/azure/google compute/other ranges and auto-blocks / unblocks them. SQL^{Query me!} 04:32, 27 February 2019 (UTC)

What if we block school IPs, but allow account creation from school emails only and blacklist blocked emails. Advantages:

• Limited ban evasion—once someone's created an account with their email address, if they get blocked they're stuck.
• Deterrence: if we (threaten to) send emails of vandals to school administration, that's likely to deter vandals.

Main disadvantage I see is the complexity implementing the feature, as well as maintaining the whitelisted email domains. Also, doesn't help with libraries. Gaelan 💬✏️ 05:25, 26 February 2019 (UTC)

• I used to be meh about this, but schoolteacher friends and acquaintances have told me in no uncertain terms that vandalism originating from school accounts is completely unacceptable and they should be blocked. Hawkeye7 (discuss) 10:12, 26 February 2019 (UTC)

• I work in education, and many schools are quite happy that their students can't edit - as long as they can read articles - as they don't like an IP page with their school name emblazoned on it followed by a whole list of vandalism warnings, and I can quite understand why. Black Kite (talk) 10:20, 26 February 2019 (UTC)

• Schools and libraries only get blocked for time periods of months if they have persistently been outputting nothing but vandalism for a considerable time. There will have been multiple blocks for a much shorter time before that happens. There are many schools out there where the internet access is not supervised or controlled who have had long blocks for years. It is almost guaranteed that soon after the block expires vandalism will start again, but we always give them a chance and refrain from blocking until that actually happens. There's no other site out there that would put up with that. Anywhere else, once you're blocked, you stay blocked. SpinningSpark 00:44, 5 March 2019 (UTC)

Photos with only a GFDL license

I have noticed some photos recently with only a GFDL license in the form of "GFDL-user|migration=not-eligible". I'm tagging the ones I find with a {{Do not move to commons}} template, as commons has ceased accepting GFDL only licenses for photos since 15 October 2018 - see c:Commons:Licensing#GNU_Free_Documentation_License. Would it not make more sense for Wikipedia to follow the same policy? Ronhjones  ^(Talk) 17:06, 26 February 2019 (UTC)

Question: Per [ https://www.gnu.org/licenses/fdl-1.3-faq.html],

"Section 11 has been added to allow wikis like Wikipedia to use FDL-covered works under the terms of CC-BY-SA 3.0 if they choose to do so. They have told us that they would like to explore this option, and adding this provision gives them a clear path to do so."

"Normally, these sorts of licensing decisions can and should be handled by the copyright holder(s) of a particular work. However, because Wikipedia has many copyright holders, the project needed some alternative way to accomplish this, and we've worked with them to provide that."

The above was added in 2014, yet to my untrained eye the actual text of section 11 at [ https://www.gnu.org/copyleft/fdl.html ] doesn't appear top do what the above says it does, and instead has some November 1, 2008 and August 1, 2009 deadlines. Or maybe the legal language is confusing me. --Guy Macon (talk) 17:23, 9 March 2019 (UTC)

I agree but am not a lawyer either. It is a time-restricted one time opportunity that if unused is lost. ~ ToBeFree (talk) 12:58, 12 March 2019 (UTC)

If a GFDLd file is useful on Wikipedia, then I think it is acceptable to host it here, even if commons does not accept it. So we should not change the rules to exclude them. We should discourage or deprecate new uses of the license here though. How big is the problem? Graeme Bartlett (talk) 12:57, 5 April 2019 (UTC)

Unify alternative names for articles with spelling differences

Moved to WT:Manual of Style/Lead section § Unify alternative names for articles with spelling differences

The article American and British English spelling differences includes a lot of words that are Wikipedia articles themselves. Reading through them I noticed that there is no uniform way in which the alternative names are presented. See below a small sample of the first sentence of some articles (references also copied from the articles):

• rumor (American English) or rumour (British English; see spelling differences)
• Color (American English), or colour (Commonwealth English)
• caliber or calibre
• fetus or foetus
• license (American English) or licence (British English)
• Hemoglobin (American) or haemoglobin (British)

References

As you can see, there are too many different ways in which the spelling differences are presented.

The proposal is to update the first sentence so that it is uniform and just contains the alternative names in bold, with no link or reference since the main topic has nothing to do with American or British pronunciation in most cases. Vpab15 (talk) 23:33, 26 February 2019 (UTC)

• Support as proposer Vpab15 (talk) 23:34, 26 February 2019 (UTC)
• This is about the content of the article. You should raise the issue at Talk: American and British English spelling differences, not here. –Ammarpad (talk) 04:44, 27 February 2019 (UTC)

  Vpab15 is actually talking about the leads of the various talk pages, so can't raise it there; probably MOS:LEAD or some MOS page's talk page would be the best place to raise this. Galobtter (pingó mió) 05:21, 27 February 2019 (UTC)

  Thanks, moved discussion to Wikipedia_talk:Manual_of_Style/Lead_section#Unify_alternative_names_for_articles_with_spelling_differences. Vpab15 (talk) 14:16, 1 March 2019 (UTC)

Proposal to make TfD more RM-like, as a clearinghouse of template discussions

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Templates for discussion#RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions.  — SMcCandlish ☏ ¢ 😼  05:17, 27 February 2019 (UTC)

Translation differences

I'm considering translating https://en.wikipedia.org/wiki/Bradycardia into Dutch. There is already a page there, https://nl.wikipedia.org/wiki/Bradycardie but not only is it very brief and lacking references, it also has contradicting information.

Is it appropriate for someone like me that doesn't have primary knowledge on the subject to translate the English page into Dutch, overriding the content on the Dutch page and reusing the English language references?

Aethalides (talk) —Preceding undated comment added 12:06, 27 February 2019 (UTC)

I think it would be better to ask that question on the Dutch Wikipedia, because it is their article that you would be changing, and they may have different policies and guidelines from ours. Phil Bridger (talk) 12:11, 27 February 2019 (UTC)

Wikimedia Foundation re-branding discussion/planning

See the recent Foundation blog post at Leading with Wikipedia: A brand proposal for 2030 and the ongoing discussion on Meta at m:Communications/Wikimedia brands/2030 research and planning/community review. Just dropping a few public notifications since I'm not sure this project has been otherwise notified. GMG^talk 15:03, 27 February 2019 (UTC)

Future routes in airline destination tables

There's a long and continuing edit war going on at Sofia Airport (and several other airport pages, but curiously only a select few) regarding removal of future routes from airline destination tables. Typically, as evidenced at airports worldwide such as Dubai International Airport#Airlines and destinations, Phoenix Sky Harbor International Airport#Airlines and destinations, Melbourne Airport#Airlines and destinations, and Jomo Kenyatta International Airport#Airlines and destinations, describing our current general policy shows future routes can be listed in destination tables if properly sourced. The edit war goes in circles, though, since the reverting editors continually cite WP:PROMO, WP:CRYSTAL and WP:NOTTRAVEL. I don't think any of those actually apply - we note all future routes objectively, so we're not advertising them, we require sources for routes per WP:CRYSTAL (and never have any problems finding sources). Finally, WP:NOTTRAVEL has had a sticky past with transportation articles since anything transportation related is necessarily travel related, and it seems that either the entire airlines and destinations table fails WP:NOTTRAVEL or none of it does. (I strongly believe it does not – I use the information encyclopedically to do basic research on transport routes/city and airport connectivity.) But I wanted to pose the question at a place where non-airport editing users might see it: Is the rule "Future routes may be included in an airport's airlines and destinations table if properly sourced" an accurate reading of our current policy? Thanks in advance. SportingFlyer T·C 14:14, 28 February 2019 (UTC)

ArbCom questions

I have two ArbCom-related questions.

What comes next?

What is the best venue for the current dispute at Wikipedia:Arbitration/Requests/Case to continue at if it is not heard by ArbCom? Qzekrom 💬 ^they_them 18:50, 6 March 2019 (UTC)

Participating in ArbCom

(Moved from Wikipedia:Village pump (miscellaneous))

I believe that the current dispute at Wikipedia:Arbitration/Requests/Case should be heard by ArbCom, but I don't know what I could say that hasn't already been said by the other users that posted statements. Basically, I agree that some aspects of this dispute have already been resolved or can't be resolved through arbitration, but I think other parts of it (the conduct stuff) can't be resolved effectively except through arbitration. What should I say? Is what I have written here enough? Qzekrom 💬 ^they_them 06:46, 6 March 2019 (UTC)

This is already being discussed in multiple places. Do not try to spread it elsewhere as well. Natureium (talk) 19:03, 6 March 2019 (UTC)

Natureium, I don't want to discuss the issue itself here. I came to VPP because I wanted advice on how (and whether) to get involved in the discussion in the proper venues. Qzekrom 💬 ^they_them 23:09, 6 March 2019 (UTC)

• I would say to just let the matter go. If it is the consensus of the community, and if ARBCOM also concurs, that there is nothing more to do, then there is nothing more to do. If the matter persists into the future, that is if the kinds of behavior that led to the ARBCOM filing, continue repeatedly, we can revisit the matter, but if nothing else bad happens going forward, there's no need to continue pursuing anything. --Jayron32 19:05, 6 March 2019 (UTC)

  @Jayron32: It looks like ArbCom is settling on deciding that the case would best be handled in another venue. There is one aspect that I predict will come up again in the near future, and that leaves me concerned. So far I'm not really doing anything, but I want to see which way it goes. Should I push to get it addressed now or wait for it to come up again? Qzekrom 💬 ^they_them 23:20, 6 March 2019 (UTC)

  I would say it would better sum up the results of the ARBCOM discussion that the committee roughly believes that the community has handled the issue in other venues. The two most recent decline votes basically say as much, and one of the few accept votes, that of SilkTork, basically declines all aspects of the case as "the community already dealt with this" except for one small issue, and there is not much consensus, among either the community at large, or other ARBCOM members, that the particular issue he thinks needs dealing with is an issue at all. (particularly relevant is Ivanvector's comments regarding the appropriateness of prosecuting whistleblowers...) In all, I would say that ARBCOM isn't saying the community needs to do more to deal with the issue, they're largely saying that it has been dealt with, and that there isn't any good reason to keep this fire burning any longer. --Jayron32 11:24, 7 March 2019 (UTC)

Depends on what exactly you want to achieve, but usually an WP:RFC, at either WP:VP or WT:SIGNPOST would be the way to go. I'd wait until the Signpost makes a statement before doing so, personally, but Bri has yet to come back from his Wikibreak due to the situation. Headbomb {t · c · p · b} 23:31, 6 March 2019 (UTC)

RFC probably, depending on what you're trying to achieve. But if you want remedies and AC doesn't take up the case, there's no other choice but a request for comment, that is the only binding method possible, and one that ArbCom doesn't have a choice to reject or not take up. --QEDK (後 ☕ 桜) 19:00, 7 April 2019 (UTC)

Russian disinformation on Wikipedia

Is anyone aware of any past or current discussions about Russians potentially engaging in government-sponsored disinformation on Wikipedia? To be clear, I don't mean accusations pointed at specific editors. I'm thinking more of VPP discussions about the problem more broadly, detecting if it exists and how it might be addressed. After all, we know Russian disinformation is on all major social media platforms, so why wouldn't it be on Wikipedia? I know I'm not the only one thinking about this. And Russia was caught doing this at least once, though in a ham-handed way in 2014. Please ping me, as I won't be watching this page. R2 (bleep) 17:30, 8 March 2019 (UTC)

I don't think I've seen any particular "Russian" effort, but that's probably because there are always POV pushers all over Wikipedia so that one more campaign does not necessarily stick out. Jo-Jo Eumerus (talk, contributions) 19:28, 8 March 2019 (UTC)

I agree. There are all sorts of people, including those organised by or editing in support of states, who behave in this way. There are some who make themselves obvious and get blocked or banned quickly, and there are some others who make lots of good edits but show their true intentions in a particular area. All we can do is to be vigilant. And, by the way, if you want to see the responses to your edit then do put the page on your watchlist. It's not up to other people to obey your commands about pinging. Phil Bridger (talk) 19:41, 8 March 2019 (UTC)

Geesh, I was just asking for a courtesy, you were under no obligation to comply. Anyway, the thing that makes Russia different from other POV pushers is that the Russian online international disinformation effort is by far the biggest in the world and is well-documented in the reliable media. I've been wondering for some time whether the armies of editors who push for certain POVs on certain pages are in fact paid by the Internet Research Agency or related entities, in violation of our TOS. Whether that is something that can or should be investigated or addressed would be an open question. I'm merely trying to educate myself on whether this has been discussed in the past. R2 (bleep) 20:07, 8 March 2019 (UTC)

Personally, I don't think that the pro-Russian POV-pushers are worse than any other POV-pusher, and we have a wide variety of them from antivaxxers to ufologists. Which might say that this IRA isn't active on Wikipedia. Or it might say that IRA-sponsored POV-pushing is no worse than the other kinds of POV-pushing. Jo-Jo Eumerus (talk, contributions) 19:47, 9 March 2019 (UTC)

Speaking of anti-vaxxers, a recent study found a Russian involvement: [12]. This is how they work, they get involved in controversial topics and blow it up and amplify it for the purpose of sowing FUD. The Russians were famously behind the myth that AIDS was a US government conspiracy. The Russians "promote discord" and it works! -- GreenC 20:16, 9 March 2019 (UTC)

I don't doubt at all that Russians are involved in spreading misinformation - you will see that I have in the past had run-ins with conspiracy theorists, who may or may not have been sponsored by the Russian government, on the article that you linked and others where people tried to spread nonsense about HIV and AIDS, but there are plenty of others apart from Russians who engage in such activity. We should be careful about all POV-pushers, not just Russians. Phil Bridger (talk) 20:31, 9 March 2019 (UTC)

We also shouldn't minimize or discount it, either. -- GreenC 04:05, 10 March 2019 (UTC)

I'll be so happy, if & when the new McCarthy era comes to an end. GoodDay (talk) 20:10, 8 March 2019 (UTC)

• I'd be surprised if we didn't have some Russian state editors on the site (between here and their own Wiki, I'd imagine). However, nothing particularly has jumped out - there's lots of ranting on the Crimea page and I suppose either side could be them, but nothing that indicates evidence on the issue. — Preceding unsigned comment added by Nosebagbear (talk • contribs)
• Probably not, it's best not to worry about stuff till we have evidence we need to worry about it. And considering America's legislature isn't averse to editing Wikipedia, there's not much wiggle room when it comes to finger-pointing. SITH (talk) 16:43, 9 March 2019 (UTC)
• You might find some stuff in the archives of User talk:Jimbo Wales, which is the natural home for this sort of discussion. I'd agree with others that few campaigns are going to make a successful difference on this wiki. However, I wouldn't be surprised if Russia's English Wikipedia efforts concentrated on influencing secondary sources. For example we have over 1,000 links to Sputnik, which is something I wouldn't normally recommend. -- zzuuzz ^(talk) 16:52, 9 March 2019 (UTC)
  • Basically this. Every time you see a link to Russia Today or Sputnik, you are seeing the effects of Russian propaganda and social engineering efforts. These sources exist for no other reason other than to populate the public discourse with the official government position. Some of these people may be active agents of the movement, proactively trying to add these to push a POV. Others may have just found a "source" that they intuitively agree with or that fits their preconceptions, and so they use it more as a dupe than as a co-conspirator. There is no real difference for our purposes. GMG^talk 17:08, 9 March 2019 (UTC)
    • I agree that that is the case when such sources are used for anything that is controversial, and that also goes for many of the non-Russian sources that are accepted uncritically as reliable, but they are reliable for such things as who has been appointed to which official position or for the football results. Sources are only reliable or unreliable according to the context. Phil Bridger (talk) 18:06, 9 March 2019 (UTC)
      • No. These sources only exist for the purpose of operating a propaganda arm of the Russian government. If you really need a source for the mundane details of the latest football match, then there are surely plenty to choose from, and no reason to use these in particular. The only reason the US Department of State doesn't give you the stats on the latest game is because the US DoS isn't trying to masquerade as a news agency. GMG^talk 18:17, 9 March 2019 (UTC)

(cough, cough) Radio Free Europe/Radio Liberty..... Carrite (talk) 11:54, 29 March 2019 (UTC)

• Significant programs of interference in social media exist in Russia, China, Iran, North Korea and a few others - and Wikipedia's open culture is dangerous and antithetical to those regimes. There is no question Wikipedia is on the list of sites to influence, we are the top 5 site in the world, get the top google hits and "anyone can edit" - of course they are. I read an article about this concerning Wikipedia (forget where) describing how IPs and socks don't work well, so the trick is to use long-term reputation accounts ("unblockables") and even admin moles. Personally I think that method is too expensive and low impact. A cheaper method would be to undermine and confuse reality (and Wikipedia's reputation) by quietly injecting wrong and distorted information that has no apparent bias looks like incompetence. This is essentially how they undermine the free press, by creating confusion and a mix of false and true, it is misdirection trick you don't know who to blame or trust, it keeps authoritarians from being ousted. -- GreenC 17:45, 9 March 2019 (UTC)

You're thinking of the New Statesman article I linked to in my original post. Ha. R2 (bleep) 06:03, 10 March 2019 (UTC)

Hah! Yes that is a very good article. -- GreenC 16:02, 10 March 2019 (UTC)

• My personal concern is not so much about POV warriors--in general we know how to deal with those--and more from editors who might be strategically disrupting specific articles or discussions in order to inhibit article development in certain undesired ways. The "strategic disruptor" wouldn't need to show a pro-Russian bias, or any bias at all. Their agenda would be hard to detect, and if they were careful, they could evade admin attention long enough to cause long-term damage. And by damage I don't necessarily mean POV content, I mean non-POV editors being pissed off or distracted and, for example, not developing an article on some topic Russia would like to suppress. R2 (bleep) 06:18, 10 March 2019 (UTC)

And I will add, building on GreenMeansGo's comment, when I see disruptive editors seeking to add post-1932 U.S. politics sourced to Russia Today or Sputnik, I do begin to wonder. And when those editors make awkward, unsolicited references to being American when no one ever asked them about their nationality, that makes me wonder even more. R2 (bleep) 06:24, 10 March 2019 (UTC)

• Response. R2, to answer your original question: Wikipedia:Administrators' noticeboard/IncidentArchive1002#Editor with ties to Russian government. Yes, that was one specific editor, but it contains some more information about the problem. This link contains some really good reading for any interested. The problem is not isolated to Russian state contractors. –MJL ‐Talk‐^☖ 20:58, 10 March 2019 (UTC)
• This is a relevant Wall Street Journal story from last month about how Russian disinformation trolls used Wikipedia in conjunction with Twitter and Tumblr to promote fake news in 2015. They created a hoax story about a food poisoning attack in New York, then created a Wikipedia page about it (2015 New York poisoned turkey incident), then tweeted about it thousands of times. Fortunately the WP hoax page was spotted by WilliamJE and speedy deleted. I don't know how he spotted it. 4 sockpuppets were detected and blocked. Interestingly, the 4 socks were created during the same 2-day span (May 20-21, 2015) but had very different editing patterns before being caught. None did any POV pushing that I could find. One of them, Jenniohra (talk · contribs · deleted contribs · logs · filter log · block user · block log), did a fair amount of editing relating to American white supremacists. R2 (bleep) 18:49, 11 March 2019 (UTC)
  • I don't recall at all why I smelled a hoax. It could have been the article's poor sourcing and the fact no Mainstream media (MSM) was picking it up. I worked for a MSM outlet for a while. Maybe it has given me a stronger bullshit detector. Here[13]and here[14] I found WP articles, including a GA, with serious misinformation/errors in them. I call it 'bullshit with a reference' pardon my French.

Anyway, if any administrator sees this I wouldn't mind getting a copy of that deleted article in order to further jog my memory. Thanks in advance....William, is the complaint department really on the roof? 21:13, 11 March 2019 (UTC)

I'd like to see its edit history as well. R2 (bleep) 17:00, 13 March 2019 (UTC)

Ahrtoodeetoo, CambridgeBayWeather restored it at User:WilliamJE/Hoax. Galobtter (pingó mió) 05:37, 14 March 2019 (UTC)

• Wikipedia:Disinformation -- GreenC 20:16, 11 March 2019 (UTC)
• I think the case with Russia is probably similar to usual practice in POV pushing: hired meatpuppets exist, but their efforts probably pale in comparison to those of bona fide believers relying on dubious sources, or just going with whatever suits their third-party POV agenda. Daß Wölf 22:45, 13 March 2019 (UTC)

Disinformation is distinct from POV editing, vandalism and COI. -- GreenC 23:51, 13 March 2019 (UTC)

• Comment on OP. I am sure it goes on all the time, as do both state-sponsored and personal ideological peddlers of bias from around the world. If you were to ask me, which country has the biggest community of nationally-biased editors I would be hard put to identify one from say the East-West, India-Pakistan, Arab-Israeli or any other major global tension. Then of course there are the endless religious, pseudo-scientific and other contentious issues. Making a special fuss at high level about any one of them might encourage them to think that they were someone special. They are not. We should deal with Russian state abuse the same way we deal with all of it - stolid and persistent detection, identification, protection, and move on to the next incident in the queue. In other words, business as usual. — Cheers, Steelpillow (Talk) 12:59, 8 April 2019 (UTC)

About graphic nude photos

I am not talking about censoring that, but can we make a system that we will make the image folded (i forgot the accurate word) and if anyone put the cursor on the image, it will show a message, that the image has graphic nudity, and also a show option will be given with the message. If any user want to see the picture, he or she will click the show option. If he or she doesn't, he or she will not click the show option. I think the idea is more democratic than the present policy. Waiting for all other's responses. Love for Wikipedia. Sharif Uddin (talk) 02:58, 10 March 2019 (UTC)

Nope. For many, many reasons. First, WP:NOTCENSORED. Second, people would now need to flag 'nudity' in images. Second, this is an extremely slippery slope. First it's nudity. Next it's bad words. Then it's ideas. Headbomb {t · c · p · b} 03:08, 10 March 2019 (UTC)

@Sharif Uddin: maybe try User:Anomie/hide-images --DannyS712 (talk) 03:10, 10 March 2019 (UTC)

Historical reference - something similar to this was proposed some time ago. I was on the "managing the vote" side of things so wasn't paying too much attention to what happened with the results, but it's pretty clear that the broad global community was pretty evenly split on the "worth investing in" vs. "not worth a nickel" spectrum. That was pretty much the last we ever heard of the idea. The biggest challenge is not so much the intentionally placed graphic images (whether of nudity or other potentially "shocking" material); if one opens an article about human reproduction or war atrocities or certain medical conditions or artists whose work includes nudes, it's likely that at least one graphic or NSFW image will be present. No, the bigger issue is when these kinds of images turn up unexpectedly on pages or articles where they don't really seem to fit. There's no really effective way at this time to immediately identify and 'tag' an image with graphic content at the time it's uploaded. Risker (talk) 03:20, 10 March 2019 (UTC)

It is very embarrassing for me to edit on wikipidea in front of everyone of the office in a desktop computer. Yesterday, in front of one of my coligue I openes an article, and I didn,t khnow that the photo contain nudity, when I opened the article it came out with a photo recently taken by camera including a complete uncovered people on the top of the article, and from then a negetive idea about me has been silently born on his mind. My family already started thinking me negatively because they I edit in wikipedia, and it is full of open graphic nudity. I think it is similar to a torture on the editors to make them seeing this photos who do not want to see this, and making them deprived of sharing the experience of wikipedia with othrs. I will not try to attack your ethics, you should not attack mine, but we all have the equal rights to get a neutral preview of wikipedia to enjoy the informations, becaousse wikipedia is of all. Sharif Uddin (talk) 12:07, 10 March 2019 (UTC)

I think a vote such like this should be again started meta:Image filter referendum/en. Sharif Uddin (talk) 12:58, 10 March 2019 (UTC)

Sharif Uddin, if the article included a nude photo that was a surprise, it's possible that article shouldn't include a nude photo. If you let us know which article it was, maybe we can offer other opinions. valereee (talk) valereee (talk) 13:07, 10 March 2019 (UTC)

It was exhibitionism, and as a muslim, it is also my duty to maintain my haya and refrain myself from Fahisha.I will not or never tell you to censor them, but I think as a human being, I also have the right to enjoy my religious or personal ideology in wikipedia's policy equally as other user's enjoy and make impact on them, so I think wikipedia should keep an opportunity to hide these pictures for a user. I don't know wheather all other muslim users will agry with me or not but most probably bost of them will agree with me including some or many other users. Sharif Uddin (talk) 15:00, 10 March 2019 (UTC)

As an encyclopedia, articles on subjects related to nudity will have nude images. The best solution here is for you to not visit pages on topics related to sex or nudity. A second solution would be for you to use work computers for working rather than editing wikipedia. Natureium (talk) 15:09, 10 March 2019 (UTC)

I thought, i would have a better response than that, but no problem. Still now I will remain in my request to all of you to make a better solution for it. Sharif Uddin (talk) 15:18, 10 March 2019 (UTC)

i was editing the article tazkiah in bengali wikipedia, there was a term Riya which is similar to "the tendency of showing of something", in english wikipedia there is a link added ostentation. so I started sarching the word exibition (in bengali "prodorshon") to link with it, the translated article came out in the search result as the name "Prodorshon Batik" (Show off disease or disorder), I clicked on hte link and then it happened. Same kind of occurance happened many time in English wikipedia, and it is undeniable that all other language based wiki community just follow the english wiki policy and most often translate the english wikipedia rather than hardly or poorly transforming it according to their own culture. In bengali wikipedia, there is all agreed community policy that real photography of graphic nudity is not allowed but artwork is allowed, so in bengali wikipedia, I removed the image, but the same problem I face on enlish wiki, I think a don't have the right to tell it to make it censored, but as a wikipedian like other wikipedians, I must have the right to ask wikipedia to make an opportunity option for the users to hide it, javascript is ess havenot worked today as I tried, so I think making a better option will work and make the rights equal. Sharif Uddin (talk) 15:26, 10 March 2019 (UTC)

@Sharif Uddin: Did you have a look at User:Anomie/hide-images as suggested above? --bonadea contributions talk 15:30, 10 March 2019 (UTC)

I just checked now, it doesn't work. Sharif Uddin (talk) 15:44, 10 March 2019 (UTC)

Sharif Uddin, it doesn't work for you because you didn't follow the installation instructions. User:Sharif Uddin/common.css needs to be exactly what it says in User:Anomie/hide-images. The script does work for me on Exhibitionism for example. Not that I would ever use it, other than for testing. I find all forms of censorship, including self-censorship, abhorrent. Vexations (talk) 23:51, 10 March 2019 (UTC)

"as a muslim, it is also my duty to maintain my haya and refrain myself from Fahisha" You do realize that it is not incumbent on us (either as individuals or as the collective Wikipedia) to help you maintain your personal principles or help you refrain from doing or seeing things that upset you? We do not need to "make a better solution" as there is no problem on our end. The problem is entirely your own. If you do not wish to see these things, then don't look at them. --Khajidha (talk) 19:24, 2 April 2019 (UTC)

If I intentionally viewed an article titled exhibitionism, I would expect it would include images of exhibitionist behavior, i.e. nudity. There are many types of content on the internet (and in the world in general) which I do not wish to see. For the most part, I self-select what I'm going to look at. I only get upset when I'm tricked into looking at something I didn't want to by a misleading title, unexpected pop-up, etc. As long as it's appropriately labeled, I can make my own informed decisions about what to access.

That being said, one of the nice things about wikipedia is that all of the content is freely available for anybody to do whatever they want with. Artificial intelligence has advanced to the point where it's quite feasible to have a computer detect nudity in images. It seems like it would be a useful project, for an interested person or group, to systematically examine all of the images contained in wikipedia and assign them tags describing aspects of the image which might be offensive to various groups. This collection of tags could then also be made publicly available, and people could build software that takes advantage of them. I could envision a browser plugin which, before it displays each image, would do a lookup in this database and decide to show or hide each image according to whatever set of rules the user has configured. I suspect many people would find such a system useful, and building it would be entirely within the spirit of wikipedia. -- RoySmith (talk) 15:47, 10 March 2019 (UTC)

Many many many many many many many many many support as a proposer. ♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥ I am tooooooooooooo much happy that I have got apositive response, Again LOOOOOOOOOOOOOOOve ♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥ to Wikipidiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Sharif Uddin (talk) 15:54, 10 March 2019 (UTC)

This is more or less what commons:Commons:SDC will do/enable directly. --Izno (talk) 16:25, 10 March 2019 (UTC)

Again thanks for another response!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥ Sharif Uddin (talk) 16:40, 10 March 2019 (UTC)

We do not need the hyperbole. Please be more gentle with your keyboard. --Izno (talk) 16:48, 10 March 2019 (UTC)

RoySmith, I had the same thought initially–well, if you want to avoid nudity, don't click on exhibitionism–but then it occurred to me that you and I know what that word refers to, but others–particularly non-native English speakers–may not understand that "exhibitionism" isn't just a synonym for "show off". Perhaps easier than an AI to filter the images would be a little [[[NSFW]]] tag that appears after wikilinks to NSFW articles. It could be a script/gadget so editors could turn the NSFW tags on or off depending on if they wanted them. The hard part would be compiling a list of all the "NSFW" articles, but that could actually probably be done semi-automagically using categories and keywords (and also by looking at the categories that images in the article are tagged with). So if an article is in an NSFW category, has NSFW keywords, or has an image that is in an NSFW category (like "nude"), then it would get the NSFW tag after the link (if the user had that feature enabled), so users would be warned not to click on NSFW links. Leviv ich 17:02, 10 March 2019 (UTC)

Anything addressing this needs to take account of the fact that different readers find different things offensive, especially in a world-wide encyclopedia such as this, so any global "NSFW" tag will not work. For example, on an individual level, I don't have any problem with nudity but am very squeamish when it comes to pictures of medical operations, particularly if internal organs are visible. And there are also cultural differences. In general (although there are, of course, many individual exceptions) Europeans are more accepting of casual, non-sexual, nudity than Americans but less accepting of violent images, and there are other differences in all cultures. And, of course, such issues exist all over the Internet, not just on Wikipedia. I think it would be best, if people are offended by a particular type of image, to use some sort of global solution that applies to all web sites (surely there are browser add-ons on the lines of AdBlock that can be configured to the user's requirements?) rather than develop something that only works with Wikipedia. Phil Bridger (talk) 17:30, 10 March 2019 (UTC)

@Levivich: See Wikipedia:Templates for discussion/Log/2019 February 14#Template:NSFW and Wikipedia:Templates for discussion/Log/2019 March 4#Template:NSFW --DannyS712 (talk) 00:00, 11 March 2019 (UTC)

DannyS712, wow thanks for that, I didn't realize this was a current topic of discussion. But anyway I wasn't suggesting a template, I was suggesting more like a script, that would essentially be like a link highlighter, highlighting any link that pointed to a page in a certain category (e.g., pornography). Then people would know not to click on the link. Only those who wanted the highlighter would install/enable it. No one would have to go around tagging stuff "NSFW." Leviv ich 03:13, 11 March 2019 (UTC)

I am so much happy that I have got a lot of positive response. Thank you all. Sharif Uddin (talk) 09:11, 11 March 2019 (UTC)

I just followed Vexations and the anomie js worked but I also differently followed the Z-man's bad image js but it didn't work. And initially I dont want to hide all image except the graphic nude images (It would be better for me including semi-nude pictures, but now only graphic nude will at least work.), It will be very irritating for me to do it manually again and again. And also it completely spoils the attention of the work then i intend. Sharif Uddin (talk) 09:54, 11 March 2019 (UTC)

To comment further on "the bigger issue is when these kinds of images turn up unexpectedly on pages or articles where they don't really seem to fit. There's no really effective way at this time to immediately identify and 'tag' an image with graphic content at the time it's uploaded." – More to the point, we have a large editorial pool, including a lot of people devoted to anti-vandalism and anti-trolling. If you stick a cock picture in Star Wars: Episode I it won't be there long. This is basically a "solution" in search of a problem.  — SMcCandlish ☏ ¢ 😼  14:32, 12 March 2019 (UTC)

I think probably most editors would agree that the fact that users of the encyclopedia are unexpectedly confronted with material that is shocking or traumatic to them is at least an issue; maybe it is time to revisit the matter of content/trigger warnings. They could be the most principled way to deal with Sharif's issue. But not such an easy task: see Wikipedia:Perennial proposals#Content_warnings and Wikipedia:No disclaimers in articles.

The counterarguments there seem possible to tackle: I'm reminded of Scott Alexander's "I still really want an Official List of Trigger Warnings, looked at and endorsed (if grudgingly) by An Assembly Of Reasonable People"; if any assembly can do that, Wikipedia can. The use of content/trigger warnings is that they can appear in popups, be a basis for article exclusion by user preference according to whatever technical choice is favoured, and perhaps eventually influence search results. It makes most sense to say that the topic concerns, say, human sexuality or suicide, rather than the actual contents of articles, since the latter are relatively transient and judgements about them perhaps more likely to be subjective.

Does anyone else think this topic is worth raising? — Charles Stewart (talk) 13:22, 16 March 2019 (UTC)

I think there are valid points that deserve more examination. Otr500 (talk) 12:24, 29 March 2019 (UTC)

"I think probably most editors would agree that the fact that users of the encyclopedia are unexpectedly confronted with material that is shocking or traumatic to them is at least an issue" Nope. Readers of an encyclopedia should EXPECT to come across things that will upset them. Encyclopedias deal with the real world. And the real world doesn't give a pile of fetid dingo's kidneys about your feelings. The only "warning" you need is the fact that this IS an encyclopedia. If you can't deal with that, log off. --Khajidha (talk) 17:25, 2 April 2019 (UTC)

Strong oppose per User:Headbomb. John M Wolfson (talk) 01:56, 2 April 2019 (UTC)

Continuing oppose to image hiding or other censorship. At the ideological level, Wikipedia's sole loyalty should be to the truth -- not to imposing certain cultures' unspoken rules of what is suitable for "a workplace" (whose workplace? They vary!). At the tactical level, it is better to stake out a position for Wikipedia as an uncensored textbook for an adult audience than to risk being pushed toward a role viewed as presenting to (censored) children, which would only create many more demands. And at the practical level, this is a crowdsourced, unpaid environment. Maybe Facebook has a huge team of 15,000 miserable low-paid censors working for a subcontractor [15] who can delete 1.5 million copies of the New Zealand shooting video, [16] but we don't. So there is no way you can avoid being confronted with an occasional nude on Wikipedia. The rarer you make it the more 'embarrassing' it will be when it happens, so what is there for you to gain? Wnt (talk) 14:10, 2 April 2019 (UTC)

• Oppose In the OP's personal, local community, images of nudity may be locally held to be offensive, but that doesn't mean that they are everywhere. Going to the "exhibitionism" example, such images are not universally offensive. We don't, for example, alter, remove, partially hide, or obscure with a warning, images of the prophet Muhammad, even though several hundred million people find those images offensive. If images of Muhammad are appropriate in the article titled "Muhammad", images of exhibitionism are appropriate in the article titled "exhibitionism". --Jayron32 18:15, 2 April 2019 (UTC)

References

RFC: Portals and Project Sponsorship

Since User:Iridescent has proposed, in response to my ArbCom case request, that ArbCom adopt language requiring WikiProject sponsorship for portals, I am submitting their draft language to the community for consideration.

I am including the version submitted by Iridescent as Version 1, and am requesting that the community consider it, and any alternate versions. On each version, please provide your opinions and brief comments on the Survey, and extended discussion is permitted in the Threaded Discussion.

If two or more versions are approved, the closers may determine that one of the versions is encompassed in another as a subset, or may relist this RFC to require a choice between versions. Robert McClenon (talk) 21:19, 30 March 2019 (UTC)

Version 1 (WikiProjects and portals)

Draft Language (WikiProjects and portals version 1)

All editors intending to create a portal must consult with the relevant WikiProject for that topic as to whether they feel a portal would be useful. All existing portals should be raised at the talk page of the relevant WikiProject and deleted if there is a consensus at that project that the portal is not useful. If the topic has no relevant WikiProject, it should be deleted.

Survey (WikiProjects and portals version 1)

• Neutral as scribe for this version, because I would prefer to let existing portals be discussed on their merits at MFD. Robert McClenon (talk) 21:19, 30 March 2019 (UTC)
• Support this version, now that X3 has been sent off by a supervote. Robert McClenon (talk) 16:42, 7 April 2019 (UTC)

• @Robert McClenon: There are ≈4000 existing portals, and that's before we get on to the equal if not greater number of "outline of…" pseudo-portals, most of which were created by the same editor who bulk-created the portals. Even if one were to assume that 50% of the portals and all of the outlines are self-evidently non-problematic—a huge assumption—then assuming we restricted MFD nominations to 50 nominations per week to avoid flooding the process completely it would take two years just to get through 2000 portals. Per my comments at the AN thread, this is certainly not an ideal solution and nobody on either side of the debate will like it very much, but Wikipedia's usual processes aren't really capable of handling this kind of scale without breaking (MFD typically only handles a total of 100-ish nominations per month, and most of those are usually uncontroversial deletions of drafts). ‑ Iridescent 22:49, 30 March 2019 (UTC)

Indeed when one person created 109 portals in a single day how can we review them all at MfD? This puts the onus on the person who created all this crap to find support after they ignored WP:MEATBOT and WP:POG

pages created only on Feb 11

16:44, 11 February 2019 diff hist +2,892‎ N Portal:Politics of South Sudan ‎ start portal 16:43, 11 February 2019 diff hist +2,808‎ N Portal:Politics of Sudan ‎ start portal 16:43, 11 February 2019 diff hist +3,055‎ N Portal:Politics of São Tomé and Príncipe ‎ start portal 16:42, 11 February 2019 diff hist +2,853‎ N Portal:Politics of Tanzania ‎ start portal current [rollback] [vandalism] 16:39, 11 February 2019 diff hist +2,857‎ N Portal:Politics of Togo ‎ start portal 16:39, 11 February 2019 diff hist +2,840‎ N Portal:Politics of Tunisia ‎ staart portal current [rollback] [vandalism] 16:39, 11 February 2019 diff hist +2,827‎ N Portal:Politics of Uganda ‎ start portal current [rollback] [vandalism] 16:39, 11 February 2019 diff hist +3,088‎ N Portal:Politics of the Republic of the Congo ‎ start portal 16:31, 11 February 2019 diff hist +2,901‎ N Portal:Politics of Cameroon ‎ start portal 16:20, 11 February 2019 diff hist +43‎ N Portal:Military of Finland ‎ redir current Tag: New redirect [rollback] [vandalism] 16:18, 11 February 2019 diff hist +2,536‎ N Portal:Western dress codes ‎ start portal 16:18, 11 February 2019 diff hist +2,814‎ N Portal:Wildlife of India ‎ start portal current [rollback] [vandalism] 16:17, 11 February 2019 diff hist +2,814‎ N Portal:Wildlife of Nepal ‎ start portal 16:15, 11 February 2019 diff hist +2,723‎ N Portal:Winter War ‎ start portal current [rollback] [vandalism] 16:12, 11 February 2019 diff hist +3,069‎ N Portal:Finnish Defence Forces ‎ start portal 16:08, 11 February 2019 diff hist +40‎ N Portal:World trade ‎ redir current Tag: New redirect [rollback] [vandalism] 16:07, 11 February 2019 diff hist +2,416‎ N Portal:Yugoslavs ‎ start portal 16:07, 11 February 2019 diff hist +2,762‎ N Portal:Yoruba people ‎ start portal current [rollback] [vandalism] 16:00, 11 February 2019 diff hist +2,835‎ N Portal:International trade ‎ start portal 15:57, 11 February 2019 diff hist +2,762‎ N Portal:World economy ‎ start portal current [rollback] [vandalism] 12:44, 11 February 2019 diff hist +2,697‎ N Portal:Arianism ‎ start portal current [rollback] [vandalism] 12:43, 11 February 2019 diff hist +2,717‎ N Portal:Antimatter ‎ start portal 12:43, 11 February 2019 diff hist +2,801‎ N Portal:Anti-consumerism ‎ start portal 12:42, 11 February 2019 diff hist +2,879‎ N Portal:Ancient Roman religion ‎ start portal current [rollback] [vandalism] 12:42, 11 February 2019 diff hist +2,944‎ N Portal:Ancient Near East mythology ‎ start portal current [rollback] [vandalism] 12:42, 11 February 2019 diff hist +2,684‎ N Portal:Alevism ‎ start portal current [rollback] [vandalism] 12:41, 11 February 2019 diff hist +2,827‎ N Portal:Albanian Civil War ‎ start portal current [rollback] [vandalism] 12:31, 11 February 2019 diff hist +2,853‎ N Portal:Politics of Cambodia ‎ start portal current [rollback] [vandalism] 12:30, 11 February 2019 diff hist +2,834‎ N Portal:Politics of Burundi ‎ start portal 12:30, 11 February 2019 diff hist +2,905‎ N Portal:Politics of Burkina Faso ‎ start portal current [rollback] [vandalism] 12:30, 11 February 2019 diff hist +2,853‎ N Portal:Politics of Bulgaria ‎ start portal current [rollback] [vandalism] 12:25, 11 February 2019 diff hist +2,821‎ N Portal:Politics of Brunei ‎ start portal 12:25, 11 February 2019 diff hist +2,827‎ N Portal:Politics of Brazil ‎ start portal current [rollback] [vandalism] 12:25, 11 February 2019 diff hist +2,853‎ N Portal:Politics of Botswana ‎ start portal current [rollback] [vandalism] 12:22, 11 February 2019 diff hist +3,029‎ N Portal:Politics of Bosnia and Herzegovina ‎ start portal 12:19, 11 February 2019 diff hist +2,827‎ N Portal:Politics of Bhutan ‎ start portal current [rollback] [vandalism] 12:19, 11 February 2019 diff hist +2,808‎ N Portal:Politics of Benin ‎ start portal 12:19, 11 February 2019 diff hist +2,821‎ N Portal:Politics of Belize ‎ start portal 12:19, 11 February 2019 diff hist +2,834‎ N Portal:Politics of Belgium ‎ start portal 12:18, 11 February 2019 diff hist +2,840‎ N Portal:Politics of Belarus ‎ start portal current [rollback] [vandalism] 12:13, 11 February 2019 diff hist +2,834‎ N Portal:Politics of Bavaria ‎ start portal 12:11, 11 February 2019 diff hist +2,879‎ N Portal:Politics of Bangladesh ‎ start portal current [rollback] [vandalism] 12:11, 11 February 2019 diff hist +2,834‎ N Portal:Politics of Bahrain ‎ start portal 12:09, 11 February 2019 diff hist +2,536‎ N Portal:Politics of Artsakh ‎ start portal 12:07, 11 February 2019 diff hist +2,866‎ N Portal:Politics of Argentina ‎ start portal current [rollback] [vandalism] 12:06, 11 February 2019 diff hist +2,996‎ N Portal:Politics of Antigua and Barbuda ‎ start portal current [rollback] [vandalism] 12:03, 11 February 2019 diff hist +2,821‎ N Portal:Politics of Angola ‎ start portal 12:03, 11 February 2019 diff hist +2,840‎ N Portal:Politics of Andorra ‎ start portal current [rollback] [vandalism] 12:03, 11 February 2019 diff hist +2,840‎ N Portal:Politics of Algeria ‎ start portal current [rollback] [vandalism] 12:02, 11 February 2019 diff hist +2,840‎ N Portal:Politics of Albania ‎ start portal current [rollback] [vandalism] 12:02, 11 February 2019 diff hist +2,892‎ N Portal:Politics of Afghanistan ‎ start portal current [rollback] [vandalism] 12:00, 11 February 2019 diff hist +2,847‎ N Portal:Politics of Abkhazia ‎ start portal 05:30, 11 February 2019 diff hist +2,905‎ N Portal:World Rally Championship ‎ start portal current [rollback] [vandalism] 05:29, 11 February 2019 diff hist +2,765‎ N Portal:Worcestershire ‎ start portal 05:28, 11 February 2019 diff hist +2,751‎ N Portal:West Flanders ‎ start portal current [rollback] [vandalism] 05:23, 11 February 2019 diff hist +2,681‎ N Portal:Thrissur ‎ start portal current [rollback] [vandalism] 05:22, 11 February 2019 diff hist +2,476‎ N Portal:The Living End ‎ start portal current [rollback] [vandalism] 05:21, 11 February 2019 diff hist +2,765‎ N Portal:Tamil language ‎ start portal current [rollback] [vandalism] 05:18, 11 February 2019 diff hist +2,452‎ N Portal:Terry Brooks ‎ start portal current [rollback] [vandalism] 05:16, 11 February 2019 diff hist +2,710‎ N Portal:Semiotics ‎ start portal 05:13, 11 February 2019 diff hist +2,709‎ N Portal:Saxophones ‎ start portal 05:11, 11 February 2019 diff hist +2,667‎ N Portal:Rutland ‎ start portal 05:09, 11 February 2019 diff hist +2,681‎ N Portal:Nobility ‎ start portal 05:07, 11 February 2019 diff hist +2,905‎ N Portal:Royal Canadian Air Force ‎ start portal current [rollback] [vandalism] 05:03, 11 February 2019 diff hist +2,737‎ N Portal:Ricky Martin ‎ start portal current [rollback] [vandalism] 05:02, 11 February 2019 diff hist +2,765‎ N Portal:Ras Al Khaimah ‎ start portal current [rollback] [vandalism] 04:14, 11 February 2019 diff hist +32‎ N Portal:World ocean ‎ redir current Tag: New redirect [rollback] [vandalism] 04:08, 11 February 2019 diff hist +2,904‎ N Portal:World Ocean ‎ start portal 04:06, 11 February 2019 diff hist +2,793‎ N Portal:North Queensland ‎ start portal current [rollback] [vandalism] 04:05, 11 February 2019 diff hist +2,793‎ N Portal:Nordic countries ‎ start portal current [rollback] [vandalism] 04:04, 11 February 2019 diff hist +2,863‎ N Portal:National Rugby League ‎ start portal 04:01, 11 February 2019 diff hist +2,931‎ N Portal:Music of the United States ‎ start portal 03:57, 11 February 2019 diff hist +2,779‎ N Portal:Music of Serbia ‎ start portal 03:54, 11 February 2019 diff hist +2,737‎ N Portal:Midnight Oil ‎ start portal current [rollback] [vandalism] 03:51, 11 February 2019 diff hist +2,849‎ N Portal:Maithripala Sirisena ‎ start portal current [rollback] [vandalism] 03:49, 11 February 2019 diff hist +2,667‎ N Portal:Liguria ‎ start portal 03:49, 11 February 2019 diff hist +2,653‎ N Portal:Liège ‎ start portal 03:48, 11 February 2019 diff hist +2,765‎ N Portal:Leicestershire ‎ start portal 03:48, 11 February 2019 diff hist +2,751‎ N Portal:Lehigh Valley ‎ start portal current [rollback] [vandalism] 03:43, 11 February 2019 diff hist +2,793‎ N Portal:Krasnoyarsk Krai ‎ start portal 03:42, 11 February 2019 diff hist +2,751‎ N Portal:Jordin Sparks ‎ start portal current [rollback] [vandalism] 03:39, 11 February 2019 diff hist +2,749‎ N Portal:Islamophobia ‎ start portal 03:36, 11 February 2019 diff hist +2,779‎ N Portal:Insomniac Games ‎ start portal 03:33, 11 February 2019 diff hist +2,635‎ N Portal:World views ‎ start portal 03:29, 11 February 2019 diff hist +2,860‎ N Portal:Communication studies ‎ start portal current [rollback] [vandalism] 03:26, 11 February 2019 diff hist +2,905‎ N Portal:Hunters & Collectors ‎ start portal 03:24, 11 February 2019 diff hist +2,653‎ N Portal:Hotels ‎ start portal 03:20, 11 February 2019 diff hist +2,416‎ N Portal:Grinspoon ‎ start portal current [rollback] [vandalism] 03:17, 11 February 2019 diff hist +2,821‎ N Portal:Germanic languages ‎ start portal current [rollback] [vandalism] 03:11, 11 February 2019 diff hist +2,779‎ N Portal:East Kalimantan ‎ start portal current [rollback] [vandalism] 03:11, 11 February 2019 diff hist +2,695‎ N Portal:East Java ‎ start portal 03:10, 11 February 2019 diff hist +2,793‎ N Portal:Central Sulawesi ‎ start portal 03:10, 11 February 2019 diff hist +2,821‎ N Portal:Central Kalimantan ‎ start portal 03:10, 11 February 2019 diff hist +2,737‎ N Portal:Central Java ‎ start portal current [rollback] [vandalism] 03:09, 11 February 2019 diff hist +2,681‎ N Portal:Bengkulu ‎ start portal 03:08, 11 February 2019 diff hist +2,653‎ N Portal:Banten ‎ start portal 03:05, 11 February 2019 diff hist +2,625‎ N Portal:Bali ‎ start portal 02:58, 11 February 2019 diff hist +2,821‎ N Portal:Football in Jordan ‎ start portal current [rollback] [vandalism] 02:56, 11 February 2019 diff hist +2,835‎ N Portal:Football in Croatia ‎ start portal current [rollback] [vandalism] 02:53, 11 February 2019 diff hist +47‎ N Portal:Field Hockey ‎ redir current Tag: New redirect [rollback] [vandalism] 02:52, 11 February 2019 diff hist +47‎ N Portal:Field hockey ‎ redir current Tag: New redirect [rollback] [vandalism] 02:49, 11 February 2019 diff hist +2,933‎ N Portal:International field hockey ‎ start portal 02:46, 11 February 2019 diff hist +2,905‎ N Portal:Environmental technology ‎ start portal current [rollback] [vandalism] 02:46, 11 February 2019 diff hist +2,368‎ N Portal:Ehime ‎ start portal current [rollback] [vandalism] 02:43, 11 February 2019 diff hist +2,681‎ N Portal:Dyslexia ‎ start portal 02:33, 11 February 2019 diff hist +2,756‎ N Portal:Cryptozoology ‎ start portal 02:31, 11 February 2019 diff hist +2,863‎ N Portal:Cortina d'Ampezzo ‎ start portal current [rollback] [vandalism] 02:30, 11 February 2019 diff hist +3,022‎ N Portal:Conservatism in the United States ‎ start portal current [rollback] [vandalism] 02:29, 11 February 2019 diff hist +2,849‎ N Portal:Cognitive psychology ‎ start portal current [rollback] [vandalism]

Discussion (WikiProjects and portals version 1)

• Support. The existence of an active Wikiproject is a good indicator for the existence of editors who are willing to maintain a portal. Without maintainers, the portal is just a drive by creation of junk. Active Wikiprojects can judge the suitability of a topic for a portal. MFD can not handle the huge number of autogenerated portals, but this proposal should not stop any portal from being proposed for deletion at MfD. Legacypac (talk) 21:45, 30 March 2019 (UTC)
• Support this version, as it provides greater impetus for the cleanup of existing portals, although either is better than nothing. -John M Wolfson (talk) 22:09, 30 March 2019 (UTC)
• Oppose anything of the sort per WP:CONLEVEL. WikiProjects don't get to own portals even within their topic sphere. --Izno (talk) 22:14, 30 March 2019 (UTC)

  If I'm not mistaken, the global consensus, such that there is one, is shaky as to the very existence of portals. Per ArbCom's statement on the matter local consensus can be taken into account in the absence of global consensus, which is likely to arise in a question of a given portal's existence. Perhaps an appeals process can be in order on MfD, which might be shift preference to Version 2. -John M Wolfson (talk) 22:24, 30 March 2019 (UTC)

  My comment has nothing to do with any sort of particular consensus, only a part of the spirit of the policy (specifically called out as such), which is that WikiProjects do not and can not have overriding authority on content matters. I would have little concern with a suggestion that WikiProjects can and should steward portals under their domain, but that's neither the spirit nor verbiage of this proposal, and wouldn't affect anything in the end anyway--WP:MFD would still be the only correct place to delete portals (pending some speedy deletion criterion for TTH's portals being created). --Izno (talk) 18:45, 31 March 2019 (UTC)

  Fair enough, I would also support CSD proposal X3 (Regarding TTH's portals not clogging up MfD), and with that I would support something to limit future portal creation (maybe a "Portals for Creation" page similar to WP:AfC, but for every future portal?) I could see how limiting such a process only to WikiProjects might create WP:OWN problems, so perhaps we can leave it to the global community? -John M Wolfson (talk) 19:37, 31 March 2019 (UTC)

• Support as proposer. This isn't ideal, but we need some kind of mechanism to gauge which portals are likely to be maintained and considered of potential use, and that mechanism needs to be designed to prevent both the "keep them all" and "delete them all" arguing parties away so they can be discussed by people who will view them in terms of utility rather than in terms of their personal support for or opposition to the concept of portals. I'm not wedded to this proposal, but I've not seen anyone propose anything better. ‑ Iridescent 22:49, 30 March 2019 (UTC)
• Strong Oppose - See the bullet points below for my various rationales.

• Wikiprojects are perenially understaffed and underwatched, with some having no participation for months or even years at a time on their talk pages. Some are marked as semi-active or inactive. Making it a requirement to consult with projects with such problems would amount to muzzling portal creations for many topics, because nobody may actually come along to discuss a portal proposal.
• This proposal would further denigrate Wikipedia in the wrong direction, with an increasing nanny state type of governance regarding content, where permissions have to first be made to create pages. This would result in even more chilling effects than already exist in various areas of the encyclopedia at this time.
• The proposal goes entirely against the grain of WP:5, point #5, concerning being WP:BOLD. Wikipedia having no firm rules is one of the fundamental principles of the encyclopedia. The proposal also goes against the grain of WP:NOTBUREAUCRACY in several ways.
• Regarding the notion that if a topic has no project, the portal would then be procedurally deleted: some topics may not have a direct Wikiproject, but may have a related one. For example, there is no direct project for the topic of air conditioning, but a related project would be WikiProject Engineering.

Furthermore, many of the discussions listed at WikiProject Council/Proposals receive very little input, sitting in limbo. If a Wikiproject cannot be created without first consulting a forum that receives little input, and therefore a portal could not be created without a project backing it, all without a means for a project to get off the ground in the first place, it would amount to a vicious circle of automatically denying portal creation for some topics based upon the already largely broken system at the WP Council.

• Would older portals also be automatically, procedurally deleted if no project exists, or would this only apply to the newer ones, with a grandfather clause existent for the older portals? Either way, automatic deletion in this manner goes against several core principles of Wikipedia, and would serve to unnecessarily stifle the creation of functional, useful content.
• Regarding having discussions for all existing portals raised on talk pages of relevant Wikiprojects: this is very unlikely to even be viable. Who would ultimately be responsible to perform creating and then watching all of these discussions? Would said posited discussions be a subjective straw poll, or based upon actual objective discussion about a portal's content and how it relates to a topic? Importantly, this would significantly and negatively shift Wikipedia from being a volunteer project to one that requires specific actions, in this case, mandatory discussions for all content in the portal namespace. This would set a very poor precedent for the encyclopedia.
• Regarding the notion of procedurally deleting portals if no consensus exists in a talk page discussion: at AfD, MfD, and other areas of deletion on Wikipedia, a no consensus result typically results in retention of a page or pages, rather than deletion.
• There's more, but I will leave my post at that for now.

– North America¹⁰⁰⁰ 00:24, 31 March 2019 (UTC)

With all due respect,

• If a topic doesn't have enough notability to sustain a viable WikiProject, it probably doesn't have one to sustain a portal. I know such reasoning is quite sketchy and akin to the "if you've done nothing wrong you've got nothing to hide" reasoning many authoritarians adopt, but it's important to remember that portals are not content, they are a navigational aid, one of hotly debated utility as WP:ENDPORTALS showed. I myself have created articles in the mainspace that have quite niche use, but they are content and limited to one page. Imagine if we allowed such portals as Portal:Harry C. Van Norman or Portal:1929 Chicago aldermanic elections. As such, community consensus can have more power, and any sort of chilling effect it might have doesn't matter as much so long as it doesn't apply to content as such. (Even with content we have such things as WP:NOTABILITY, but I digress.) As a personal side note, I've never really used portals myself, so my Wikipedia experience would not be affected if they were eliminated entirely, BUT I do realize that others' mileages may vary in that regard so I'm not here to denigrate them entirely.
• Being bold does not justify being reckless, especially with non-content as Portals. Also, WP:TINC, although in that regard I thank you for joining this discussion to stop there from being one.
• The point about no-consensus usually resulting in keeping for MfD is a valid one, but with this proposal the onus would be for portal retention, NOT deletion. As such, the onus would be on keeping the portal, and a lack of consensus in that regard for retention would probably result in deletion.
• I get that your main argument is one about slippery slope, but I don't think that this will apply to the mainspace, and as said before portals are not themselves content.

-John M Wolfson (talk) 01:21, 31 March 2019 (UTC)

• Oppose - prefer version 2. Thryduulf (talk) 08:41, 31 March 2019 (UTC)
• Oppose, if a portal is well made and well maintained, it should be kept. If a portal is poorly made and there is no sustainable group of editors willing to improve it, it should be deleted. Whether there is a formal WikiProject related to the topic and whether that WikiProject is alive or not can influence whether we believe a portal can be sustainably maintained, and if somebody creates hundreds or thousands of portals that they can't maintain themselves (and we have seen in many recent MfDs that also auto-portals still require maintenance), those should be deleted unless they are adopted by editors who maintain them. But I see no reason to care whether these editors are organised in a WikiProject (and there is no formal way to check anyway). —Kusma (t·c) 09:17, 31 March 2019 (UTC)
• Oppose good idea but bad in practice. WikiProjects are largely empty with no active users, so this would be a useless and futile task. I'm almost debating whether this idea is purposefully dooming the creation of portals by trying to require a long-gone group of judges to approve. ɱ (talk) 15:21, 31 March 2019 (UTC)
• Oppose. Many Wikiprojects have died and some of those that have not have fallen into, shall we say, uncollaborative habits. A rationally argued consensus against the utility of the portal at a functional, relevant Wikiproject should, however, be taken into account at any MfD. Espresso Addict (talk) 08:23, 1 April 2019 (UTC)
• Oppose - purely on the idea that wikipedia space/talk space is not the same as portal space. I edit a lot of cue sport articles; and if I was inclined to propose Portal:Cue Sports (If I was inclined), I'd have to ask the WP:CUE wikiproject, which is all but dead. I'd effectly be asking myself for permission to create a portal. However, just because there aren't tonnes of people working on the wikiproject, it doesn't mean that there aren't lots of people updating the articles, or navigating through portals. all the above being said, I wouldn't create a portal; but I wouldn't stop someone else in the same situation. Best Wishes, Lee Vilenski ^{(talk • contribs)} 08:57, 1 April 2019 (UTC)
• Oppose prefer version 2 below. There are times when, outside the scope of a WikiProject, there are going to be well-maintained portals. There will also be defunct projects with dead-end portals. --Jayron32 14:11, 1 April 2019 (UTC)
• Oppose WP:OWN has been one of our core editorial policies for a very long time. Crazynas ^t 15:54, 1 April 2019 (UTC)
• Oppose as contrary to 5 pillars and many good arguments already covered above. · · · Peter Southwood ^(talk): 08:30, 3 April 2019 (UTC)
• Beyond oppose: This is against multiple policies and multiple ArbCom rulings. Wikiprojects are nothing but pages at which editors with a common topical interest gather to discuss and evaluate articles. They have no authority of any kind over other editors and cannot have any, under WP:CONLEVEL and WP:OWN and WP:EDITING policies. This has been tested at ArbCom repeatedly, and the answer is always the same. WP has no walled gardens, no good ol' boys's clubs, no membership organizations, no topical fiefdoms. The entire notion could never work anyway, since there are virtually no articles that could not be within the scope of multiple wikiprojects, which would just set up a "projectwar". F that noise.  — SMcCandlish ☏ ¢ 😼  00:55, 14 April 2019 (UTC)

Version 2 (WikiProjects and portals)

Draft Language ((WikiProjects and portals version 2)

All editors intending to create a portal must consult with a WikiProject for that topic as to whether they feel a portal would be useful. No new portal may be created without the sponsorship of a WikiProject.

Sponsorship of existing portals is desirable but not required, and the lack of a sponsoring project will be considered as a factor in a deletion discussion at MFD.

Survey ((WikiProjects and portals version 2)

• Support as proponent of this version. This will serve as a check on future reckless creation of portals, provide a place where each future portal can be discussed, and require some degree of involvement. Robert McClenon (talk) 21:19, 30 March 2019 (UTC)
• Prefer Version 1 because it helps in the cleanup of the indiscriminately created portals and attracts interested editor attention to the portals that should be considered for keeping. This version has no teeth because it makes WikiProject support optional ie it does not matter, which is how things are now. Legacypac (talk) 21:47, 30 March 2019 (UTC)
• Prefer version 1. The Portals project appears to have abandoned their aim of flooding Wikipedia with 10,000 portals, and I can't imagine any of them would be foolish enough to start it up again without a broader discussion. The issue is how we deal with "We're at 5,705 portals and counting", not "10,000 portals, here we come...". ‑ Iridescent 22:55, 30 March 2019 (UTC)

• Strong Oppose - See the bullet points below for my various rationales.
  • Muzzling all content creation in a namespace would set a very poor precedent. Wikiprojects are perenially understaffed and underwatched, with some having no participation for months or even years at a time on their talk pages. Some are marked as semi-active or inactive. Making it a requirement to consult with projects with such problems would amount to muzzling portal creations for many topics, because nobody may actually come along to discuss a portal proposal.
  • This proposal would further denigrate Wikipedia in the wrong direction, with an increasing nanny state type of governance regarding content, where permissions have to first be made to create pages. This would result in even more chilling effects than already exist in various areas of the encyclopedia at this time.
  • The proposal goes entirely against the grain of WP:5, point #5, concerning being WP:BOLD. Wikipedia having no firm rules is one of the fundamental principles of the encyclopedia. The proposal also goes against the grain of WP:NOTBUREAUCRACY in several ways.

  Many of the discussions listed at WikiProject Council/Proposals receive very little input, sitting in limbo. If a Wikiproject cannot be created without first consulting a forum that receives little input, and therefore a portal could not be created without a project backing it, all without a means for a project to get off the ground in the first place, it would amount to a vicious circle of automatically denying portal creation for some topics based upon the already largely broken system at the WP Council.

  – North America¹⁰⁰⁰ 00:24, 31 March 2019 (UTC)

• Weak support It isn't perfect, per my comments in the parallel discussion at AN, but it's not bad. Thryduulf (talk) 08:42, 31 March 2019 (UTC)
• Oppose, the very idea of asking for permission before editing is a contradiction to the fundamental principle that Wikipedia is a wiki. (But all of the recent mass creations should be deleted). —Kusma (t·c) 09:21, 31 March 2019 (UTC)
• Oppose good idea but bad in practice. WikiProjects are largely empty with no active users, so this would be a useless and futile task. I'm almost debating whether this idea is purposefully dooming the creation of portals by trying to require a long-gone group of judges to approve. It also seems like people are searching for yet another MfD argument for deletion... ɱ (talk) 15:23, 31 March 2019 (UTC)
• Oppose per my opposition in version 1. --Izno (talk) 18:48, 31 March 2019 (UTC)
• Oppose as worded, per my Oppose to the first proposal. However I would not object to advice that portal creators should consult any relevant Wikiproject that is still active, and take into consideration any concerns raised by project members. Espresso Addict (talk) 08:28, 1 April 2019 (UTC)

  Yeah, that was about where I was sitting, but see my comment in my first opposition. --Izno (talk) 16:05, 1 April 2019 (UTC)

• Support Prefer this version. --Jayron32 14:10, 1 April 2019 (UTC)
• Oppose contrary to WP:BURO and WP:BOLD Crazynas ^t 15:57, 1 April 2019 (UTC)
• Oppose as contrary to 5 pillars and many good arguments already covered above. · · · Peter Southwood ^(talk): 08:32, 3 April 2019 (UTC)
• Beyond oppose: This is against multiple policies and multiple ArbCom rulings. Wikiprojects are nothing but pages at which editors with a common topical interest gather to discuss and evaluate articles. They have no authority of any kind over other editors and cannot have any, under WP:CONLEVEL and WP:OWN and WP:EDITING policies. This has been tested at ArbCom repeatedly, and the answer is always the same. WP has no walled gardens, no good ol' boys's clubs, no membership organizations, no topical fiefdoms. The entire notion could never work anyway, since there are virtually no articles that could not be within the scope of multiple wikiprojects, which would just set up a "projectwar". F that noise.  — SMcCandlish ☏ ¢ 😼  00:55, 14 April 2019 (UTC)

Threaded Discussion (WikiProjects and portals version 2)

I see one problem with either of these. In there heyday Wikiprojects were numerous and well stocked with participants. Now there are numerous ones that have no active editors. What happens when when a project is asked and no response is forthcoming? MarnetteD|Talk 21:29, 30 March 2019 (UTC)

That's not a bug. That's a feature. If a WikiProject is asked to support a new portal and no one answers, it has no support. If a WikiProject is asked to support an existing portal and no one answers, it is an orphaned portal, and there can be a deletion discussion. Robert McClenon (talk) 21:50, 30 March 2019 (UTC)

I had not seen the AN thread RM We can move this post there if that would be better. MarnetteD|Talk 21:32, 30 March 2019 (UTC)

My preference is to leave it here. Robert McClenon (talk) 21:50, 30 March 2019 (UTC)

Sounds good. Thanks. MarnetteD|Talk 22:03, 30 March 2019 (UTC)

What about a situation in which no one previously affiliated with the relevant wiki project supports the portal, or the wikiproject is moribund so there’s really no one there to ask, but then a newcomer to the wikiproject says “I’m signing up for the wikiproject to support the portal”? Newyorkbrad (talk) 23:14, 30 March 2019 (UTC)

I guess if they follow up with it it'd be a feature and not a bug per User:Robert McClenon's response. -John M Wolfson (talk) 23:23, 30 March 2019 (UTC)

• Comment – There is an essentially duplicate discussion about this topic presently occurring concurrently at Wikipedia:Administrators' noticeboard § Proposal 7: Toss it to the WikiProjects. North America¹⁰⁰⁰ 00:34, 31 March 2019 (UTC)

General discussion (RFC: Portals and Project Sponsorship)

The idea of having portals sponsored by WikiProjects was proposed in February by UnitedStatesian at the portal guidelines talk page. The issue is not one of ownership; it's integrating support for portals with the same interested editors who maintain the navigation boxes and articles for the topic area. Particularly if the helper templates are used, editors need to take portals into account when modifying any associated navigation boxes and articles. But in general, portals can only be successful in the long term if they are supported in the same way as the rest of the related content. Accordingly, decisions on their creation and maintenance should be made by those editors, either under the aegis of associated WikiProjects, or through other methods of identifying editors active in the area. isaacl (talk) 16:14, 31 March 2019 (UTC)

Also, it looks the ArbCom case might not go anywhere. Even without such case I still think this, or a variation of this, is a good idea. -John M Wolfson (talk) 17:04, 31 March 2019 (UTC)

The issue is not one of ownership The effect is the same: WikiProjects would WP:OWN their portals the way these proposals are crafted, rather than stewarding them. (See also WP:CONLEVEL.) --Izno (talk) 18:50, 31 March 2019 (UTC)

Personally, I am happy with other means of identifying interested editors, and since there is no criteria to be part of a WikiProject, any interested editor can be automatically deemed a part of the associated WikiProjects. The point is that just as it makes sense for a navigation box to be maintained by someone interested in a topic area, and for discussion about whether or not a navigation box should exist to take place amongst interested editors, creating, updating, and maintaining portals should be integrated in the same way with the mass of tasks done by those working on related content. Yes, in theory, the larger community could decide that a given navigation box should exist, but that doesn't really work if no one wants to create and maintain it. isaacl (talk) 19:37, 31 March 2019 (UTC)

Right, I don't think I would object to "you should request feedback from editors of interest, which may include leaving a note at a WikiProject talk page", but the musts in the above clearly don't have that in mind. :) --Izno (talk) 16:09, 1 April 2019 (UTC)

Version 3(?): Portals for creation and (maybe, though irrelevant here) X3

Perhaps something of the following could be in order:

• X3 is adopted, so MfD would not have such a high workload (See separate discussion at WP:X3)
• For future portals, a process analogous to WP:AfC, Portals for creation, is adopted as a requisite (not merely a recommendation, unlike AfC IIRC) for all future portals (not just the first portals of a given user, unlike AfC) Given that portals are not content but navigational tools and are non-mainspace, concerns about stiflement and chilling do not apply here IMO. To address concerns about stewardship PfC would be open to the global community.

The main concern I have with this is that opening it to the global community might lead to each PfC to become simply a fight between anti-portalers and pro-portalers between the merits of portals as a whole (i.e., it might devolve into simply WP:ENDPORTALS2) and not of the merits of the specific portal at hand. This doesn't address pre-TTH portals, but I believe those are of such a number to be addressable individually. Hopes this works as a compromise between the parties involved. -John M Wolfson (talk) 19:54, 31 March 2019 (UTC)

• Oppose X3 for all the reasons explained repeatedly and in detail in the proposal at WP:AN (which should have been at WT:CSD). I strongly recommend you remove it from this proposal to keep all discussion in one place. Thryduulf (talk) 08:50, 1 April 2019 (UTC)
  • Fair enough, I have removed X3 from the discussion here. -John M Wolfson (talk) 13:25, 1 April 2019 (UTC)
• Cautiously support portals for creation. It would need enforceable guidelines to ensure that all comments addressed the individual portal being proposed with (parts of) comments that address only portals in general (positive or negative) being struck or removed. Portals created outside of PfC should not be automatically deleted, but it would be a factor that can be considered in any deletion discussion. Thryduulf (talk) 08:50, 1 April 2019 (UTC)
  • Portals created outside of PfC should not be automatically deleted, but it would be a factor that can be considered in any deletion discussion. The problem with that is that it doesn't give PfC enough teeth, IMO, and makes it yet another layer of bureaucracy that doesn't fully prevent a TTH repeat. Maybe we can make any extra-PfC portal automatically PROD'd, but then the creator of the portal can just remove such tag with impunity. -John M Wolfson (talk) 13:25, 1 April 2019 (UTC)
    • The issue I see is with someone creating a new portal in good faith without realising that they should have gone through PfC, deleting that would not benefit the encyclopaedia. Automatically prodding them is a possibility, but that would require a consensus in favour of prod for portals (currently proposed somewhere, I think at WP:AN, with no clear consensus either way last I remember the proposal for this at Wikipedia:Administrators' noticeboard#Proposal 6: Proposed Deletion for portals was withdrawn by user:Pythoncoder after it received a generally unfavourable response). Thryduulf (talk) 15:59, 1 April 2019 (UTC)
      • That's fair enough, perhaps a message on that user's talk page directing them to PfC. Although we're all rather shaken by the recent shenanigans with Portals I think WP:AGF still applies and I'm not sure our consensus reached by WP:ENDPORTALS has changed in light of the recent events. -John M Wolfson (talk) 18:43, 1 April 2019 (UTC)
• Comment. Portals for Creation is something I have thought about proposing myself -- as long (as the nominator mentions) as it did not become yet another battleground between those vehemently opposed to the concept of a portal & their opposite numbers. It would need guidelines and probably a moderation team, to make sure the guidelines were followed. (Agree with Thryduulf that this discussion should not bundle in 'X3', which is an entirely different topic.) Espresso Addict (talk) 09:16, 1 April 2019 (UTC)
• Comment If this proposal is approved, PfC is the obvious acronym but WP:PFC already exists as a redirect to the essay Wikipedia:Procedurally flawed consensus. Retargetting that would need to be discussed at RFD, but unless and until Portals for Creation actually becomes a thing it will never get consensus. Thryduulf (talk) 15:59, 1 April 2019 (UTC)

  That's a bureaucracy thing. --Izno (talk) 16:09, 1 April 2019 (UTC)

  That's a rather short essay that doesn't appear to be anything close to policy, so we could just redirect it to Portals for Creation and put a hatnote on the Portals for Creation page directing the reader to Procedurally-flawed consensus. -John M Wolfson (talk) 18:43, 1 April 2019 (UTC)

  Retargetting established shortcut redirects should only ever be done with extreme caution (i.e. after fully examining the history, links, views, etc.) In this case it's probably ok to retarget as the redirect doesn't seem to have garnered much use, but it's always best to make sure. Thryduulf (talk) 20:33, 1 April 2019 (UTC)

  Perhaps. I can look through the What links here for that redirect if this gains traction. -John M Wolfson (talk) 21:34, 1 April 2019 (UTC)

  @Thryduulf: It turns out only five (!) pages link to the WP:PFC redirect, two of which are this discussion (for both the policy Village Pump and the full Village Pump), another is the full WP:Procedurally-flawed consensus page, and the other two are shortcut tables. As such, I think it's hardly an established redirect, and per WP:SNOW I doubt we need to waste everyone's time with a full RfC if Portals for Creation gets off the ground. -John M Wolfson (talk) 16:02, 2 April 2019 (UTC)

  It would (I hope!) be an RfD rather than an RfC, but yeah it does seem that retargetting this redirect won't cause issues. Thryduulf (talk) 17:00, 2 April 2019 (UTC)

• Hesitant support from me here. This would function similarly to WP:WikiProject Council/Proposals I guess? This process should not be mandatory. --Izno (talk) 16:09, 1 April 2019 (UTC)
• Strong Support - Discussion and consensus both going in and going out is what we need. The current mess with thousands of portals would never have happened if there had to be discussion before creating portals. Robert McClenon (talk) 05:31, 2 April 2019 (UTC)
• Support - This is the best option in terms of how it would work out if it went well, and I think we are capable of putting together policies that should filter out nonconstructive participation in PfCs. — Charles Stewart (talk) 14:05, 2 April 2019 (UTC)
• Comment - I created a somewhat more detailed mock-up of what PfCs would be here. If you think it'd be better at a different location feel free to move it. -John M Wolfson (talk) 17:19, 2 April 2019 (UTC)
• Oppose yet another dramaboard which would likely be populated by extremists on both sides slinging mud at each other indefinitely, with any ordinary editor interested in creating a portal getting caught in the crossfire. What we need is objective notability criteria and minimum content criteria, so there can be a reasonably objective way to determine whether a portal is justified. A set of criteria for staying in date would also help with apparently abandoned portals. Easy to use tools will help as long as they are reasonably bug-free. All the proposals here are just passing the buck and do not address the actual problem, which is insufficiently clear criteria to create or delete. · · · Peter Southwood ^(talk): 08:52, 3 April 2019 (UTC)
• Oppose – Ultimately just more red tape, unnecessary bureaucracy and layers. I agree with the notions set forth by Peter Southwood above. The best way to move forward is to focus portal matters upon the actual portal criteria at Wikipedia:Portal/Guidelines, which would be best discussed in one area, at Wikipedia talk:Portal/Guidelines, rather than having multiple discussions in multiple venues constantly occurring simultaneously. North America¹⁰⁰⁰ 23:49, 5 April 2019 (UTC)
• Oppose Editors of good reputation have made comments that have convinced me that this is not an effective solution. As an editor who is not particularly active and part time I have found wiki become more bureaucratic. We need more editors to produce content. There are many people I know who have valuable content that they and their students could produce. We need to make that task both easier and attractive. Reason for opposing - not workable. Suggest that portals started that are dormant without action for a set time be cued for auto - deletion if the portal is not completed with its content page. Isthisuseful (talk) 05:39, 7 April 2019 (UTC)
• Cautious support PfC. This will provide a check on the appropriateness of new portals, without resorting to drastic solutions. This proposal leaves unresolved portal creation criteria, and the question of what to do with the mess of existing portals, but it stops the problem from getting worse effectively. Tazerdadog (talk) 17:56, 9 April 2019 (UTC)
• Theoretical support: It would have to be non-binding, non-mandatory, just like Wikipedia:WikiProject Stub sorting/Proposals and Wikipedia:WikiProject_Council/Proposals. "Failing" to use either of those processes is not a deletion rationale. Any undiscussed new stub type or wikiproject that someone wants to delete is considered on its own merits (at WP:CfD or at WP:MFD, respectively). However, both processes weed out good-faith but poorly thought-out stub and project ideas (and shunt them into something more productive, like a stub type/cat. that already exists and can encompass the topic, or a how to start a taskforce/workgroup of an extant project). A process for portals could do similar. However, we sure as hell do not need another bureaucracy, another layer of rule-thumping and "I'd rather play police than work on the encyclopedia" crap. WP is overrun with too many control freaks already.  — SMcCandlish ☏ ¢ 😼  01:04, 14 April 2019 (UTC)

Linking to categories

Do we have any policy or guideline on linking to categories from within the main article text, just like any other article link? I cannot find any mention in WP:CATEGORY or the related advice pages. I have come across a set of articles where this is done, for example in this instance at the head of a list section more or less duplicating the category content. I reverted it as something we don't normally do and the editor concerned has asked me to justify that. — Cheers, Steelpillow (Talk) 12:37, 1 April 2019 (UTC)

Wikipedia:Cross-namespace redirects does not directly address this issue, but a similar one. In general, links from the article text to a category should not occur; links to text should usually be just links to articles. We deprecate links to the Wikipedia: namespace and to external links from the main text; there are other places on the page for those sorts of things. A linked word or phrase in the running text of an article should lead the reader to another Wikipedia article. --Jayron32 14:14, 1 April 2019 (UTC)

For running text, that is the general expectation. The given example, though, is for a "see also" type of link. I think there could be some cases where linking to a category to get a different presentation of related pages can be useful. isaacl (talk) 15:10, 1 April 2019 (UTC)

I agree with Isaacl, in running text the only reason I can think of for a link to a category is if the category itself (as distinct from it's content) is somehow relevant to the article (e.g. Category:American women novelists is relevant at List of Wikipedia controversies#2013 although it isn't linked at all), and then it should probably be presented as an external link and mentioned in the third person (per WP:SELFREF). Thryduulf (talk) 16:02, 1 April 2019 (UTC)

Even for a "see also", however, the category should be linked at the bottom of the page if the Category is relevant to the article. --Jayron32 16:05, 1 April 2019 (UTC)

WP:EGG is the general gist; SELFREF is another. I generally remove links to categories as they are exposing 'the backside'--which has a specific section of the page allowed for it (the category listing). --Izno (talk) 16:04, 1 April 2019 (UTC)

Thanks all. I note that while everybody so far agrees with me that the practice is a Bad Thing, I am surprised to see that nobody can come up with a policy or guideline which either says or obviously embraces that. For example WP:SELFREF does not say whether a link to a category counts as a self-reference, only that self-references within the category page itself should be avoided. Nor can an explicit link to a category be misconstrued as an easter egg. And yet, there are so many explicit strictures about the misuse of other namespaces that the misuse of categories is conspicuous by its absence. Maybe we are just a bunch of anal retentives and the editors who like to put category links in articles on schools are fully entitled to do so? Or, should we be updating some policy or guideline to discourage the practice? — Cheers, Steelpillow (Talk) 19:09, 1 April 2019 (UTC)

Actually, I said I could see cases where a "see also" link could usefully point to a category. I'm not clear on how to formulate a general guideline, so I would leave it to a case-by-case basis. isaacl (talk) 02:12, 2 April 2019 (UTC)

My apologies, I forgot that you had said that. You seem at least not to disagree that an in-article link to a category which duplicates a list which is also maintained in an article (whether the same or a different one) is just pointless clutter. Might I suggest a guideline along the lines of "Categories should not be linked from within the actual content of of the article, unless the listing provided by the category provides further useful information which is inappropriate to include directly in an article."? — Cheers, Steelpillow (Talk) 16:28, 2 April 2019 (UTC)

Does this really come up often enough that a guideline is needed? Thryduulf (talk) 17:03, 2 April 2019 (UTC)

Actually, I can imagine circumstances where there is a short list in an article, and a "see also" link to a category that provides a more expansive list of releveant items. Personally I think what works best is highly dependent on the topic area and what articles already exist, and so I hesitate to propose any general guidelines. isaacl (talk) 17:11, 2 April 2019 (UTC)

It is quite common in school articles to have a list of alumni together with a link to the alumni category, eg Eton_College#Old_Etonians. There is a prose description of some of the most famous, a list article of others and categories, none of which will duplicate each other. Oculi (talk) 23:51, 4 April 2019 (UTC)

I support the use of such links from school articles to "educated at" categories (as potentially useful to readers and not doing harm). See related discussion at CFD. DexDor ^(talk) 06:13, 5 April 2019 (UTC)

What if the article list and the category list are intended to be identical, as in the example I gave? — Cheers, Steelpillow (Talk) 21:30, 5 April 2019 (UTC)

In a case like that there's probably little reason for a reader to go to the category (the list is better - the category has little purpose), but as long as the category exists there may be readers/editors who want to navigate to it (e.g. in case the list is incomplete). DexDor ^(talk) 09:53, 6 April 2019 (UTC)

In a case like

Linking to categories within an article should be discouraged per the principle of least astonishment. I would support the idea of creating a guidelines for this as I find myself cleaning up such links on a regular basis. Kaldari (talk) 22:40, 5 April 2019 (UTC)

Thank you, that expresses my concern perfectly. — Cheers, Steelpillow (Talk) 08:53, 6 April 2019 (UTC)

If we are talking about "see also" links (especially those in italics) that clearly state they are to a category (i.e. the link is not piped) (as in the example given by the OP) then readers shouldn't be astonished. DexDor ^(talk) 09:53, 6 April 2019 (UTC)

Alexa rank question

Wikipedia has very widespread use of Alexa ranks in website results, but there seem to be some issues with the idea:

• As described here, there are also Nielsen NetRatings and perhaps other ratings groups. Why do we always seem to just have Alexa?
• The arrow for "decreasing" or "increasing" seems recentist to my eyes - it doesn't provide an encyclopedic sense of the site's overall course beyond whatever month an editor sampled, plus it doesn't say how much it is increasing or decreasing (there's no neutral that I know of).
• I just saw a deletion at Wikipedia:Articles for deletion/List of countries by future population (United Nations, medium fertility variant) based on the idea that a UN table of projected populations could be copyrighted information. I wasn't convinced that is true, but I should check: how many Alexa ranks can Wikipedia reproduce in various articles in a standardized format before we run into trouble? Note that an Alexa rank is not even as factual or objective as an estimated future population, since the rank explicitly is taken only from among whatever websites they survey by some means.
• Why does the infobox generally give one or more numerical ranks that mean little to us, rather than some kind of number of visitors information?
• On the other hand, if the information is not copyrighted, then could we have a tiny little inline graph, like one of those trendlines out of the new Microsoft Office products, that gets automatically made up for the site from the reported data so that we can read back at least a few years to see the total trend?

Maybe this should be at the template talk page, but I feel like only technical editors would read it there and this seems like a broad policy question affecting a vast number of pages. Really, it's a question inherent to each of the articles that use the statistics. Wnt (talk) 14:33, 2 April 2019 (UTC)

• @Wnt: please also see Template_talk:Infobox_website#Bot_Job_and_arrows - we have a BRFA on hold (Wikipedia:Bots/Requests for approval/LkolblyBot) that will update these ranking, pending on what to do about the arrows. — xaosflux ^Talk 14:56, 2 April 2019 (UTC)

  Which could also be canceled if someone decides we shouldn't maintain this information at all of course! — xaosflux ^Talk 14:58, 2 April 2019 (UTC)

  Which is the comment I made at {{infobox website}} of course. See talk page. :^) --Izno (talk) 16:51, 2 April 2019 (UTC)

• Thank you, Wnt, for bringing this up here. I don't know what the situation is like now, but I remember that some years ago bots used to get approved on the basis of their technical correctness, with little regard to whether the edits that they make are a good idea. I don't see why we should aim to reproduce one ratings company's results, and especially not the "up" and "down" arrows that are a blatant example of recentism. This is an encyclopedia, not a running commentary on one organisation's measure of a web site's popularity. Phil Bridger (talk) 17:09, 2 April 2019 (UTC)
• I agree that those up and down arrows and whatever information they convey have no encyclopedic value and ditching them is actually a good idea. – Ammarpad (talk) 07:47, 3 April 2019 (UTC)
• Oppose Alexa The amount of resources required to keep this data updated is fairly intense, a ton load of web scraping of the Alexa site is going on. This is not good. I don't see why we can't just link to the Alexa page and be done. Users can click through and discover information from Alexa like they would any other external link. -- GreenC 13:38, 3 April 2019 (UTC)

  From a technology POV, if we were to do this, would suggest the following: Rename the infobox field from |alexa= to |web_rank= (something generic). Populate that infobox field in every article with a new Lua template called {{web rank}} (or whatever). Create Module:Web rank/database which is the top 1,000 websites ranked. This file is updated once every 6 or 12 months by a bot. The template will display ranking data if the website exists in that file, otherwise it will display a generic link to Alex and/or other ranking services, but otherwise no actual ranking information. -- GreenC 21:17, 3 April 2019 (UTC)

• I also Oppose Alexa and think it should be deprecated. It seems to me to be the definition of non-encyclopedic content, the non-reliable/subjective equivalent to updating the infobox of each public company's article with its daily closing stock price, which a bot could certainly scrape from a finance website. UnitedStatesian (talk) 13:44, 3 April 2019 (UTC)

  I think of it as being closer to a company's number of employees than its stock price. A stock price is of little importance to understanding a company, unless you're an active investor. However, the number of employees gives you a rough size of the company (100,000 employees? 100 employees? You imagine very different companies for these two values, whereas a $20 stock price vs. $1000 stock price tells you absolutely nothing beyond the market cap/number of shares ratio). We maintain the number of employees at a given company, even though that value is subject to recentism. e.g. Myspace, which at its heyday had 1,600 employees but now has 150. We report the 150, and we don't just provide a link to the citation so the user can click through find out on their own. (however, I agree that the up/down arrow is of little value, especially given the short time over which it cares) Lkolbly (talk) 13:42, 4 April 2019 (UTC)

  I would think that a measure of the number of visitors would be much more important than the rank, by this analogy. I mean, if you read a company was the 4000th largest employer in the U.S. and the 15000th largest employer worldwide... Wnt (talk) 13:52, 4 April 2019 (UTC)

  For sure I could agree with that. I would absolutely support replacing Alexa with some other datasource that gave absolute number, I'm not presently aware of a reasonable alternative datasource (SimilarWeb appears to have similar data, after a quick Google search. But licensing may be an issue, I dunno). Lkolbly (talk) 14:22, 4 April 2019 (UTC)

  IMO absolute page view counts are arbitrary data, it lacks context unless you can intuit what the numbers signify. It would be like maintaining a database which isn't what Infoxbox's should be for. We can provide external links to third party sites that do web rankings and view counts as their core mission, and not get into the business of maintaining that data internally, except for the top 1000 or so (much more and it puts a load on resources). -- GreenC 15:56, 4 April 2019 (UTC)

  I dunno. Page view counts specifically maybe aren't too great, in my mind I think unique visitors would be the ideal metric. That's something you can intuit pretty reasonably, just as well as you can intuit number of employees or revenue (both of which are database-like items we maintain internally. Can you intuit what it means that Baidu has CNY 175.036 billion worth of equity in 2018?). If I see a website has a billion unique visitors, I'll think it's 1000x more popular than some other website with only a million unique visitors. But page view counts gives a roughshod approximation of that. Lkolbly (talk) 16:24, 4 April 2019 (UTC)

• ​​​​I agree with GreenC that the best approach would be to have a Lua module for website statistics. The data is meaningful in that it provides an indication of how popular a website is, so I think removing all of the data summarily would not be helpful. As noted above, there may be other metrics, but they may not be as consistently useful or readily available (most websites don't publish unique visitor statistics, whereas just about every marginally important website in the 21st century has or had an Alexa rank). Furthermore, the stock price comparison isn't necessarily accurate, since Alexa ranks represent a rolling average.

  The up and down arrows presumably match the ones shown on the website, which indicate change after 3 months (based on subtracting 3 from the month number and comparing data from that date). If the convention is consistently followed, then I think that data could be useful as well. (Tangentially, many of the arrows are reversed to indicate that lower is better; this could be a point of contention.) Jc86035 (talk) 07:37, 5 April 2019 (UTC)

• Support Alexa. As Lkolbly mentioned earlier, Alexa ranks give readers a measurement of how significant a website is. In my opinion, the best comparison from {{Infobox company}} is the company's revenue, which is a metric that provides an instant impression of the subject's scale. Both revenue numbers and Alexa ranks can be accompanied with up/down arrows and also need to need to be updated on an ongoing basis. I personally find Alexa ranks (and the arrows) to be useful information.

  Based on how the proposed LkolblyBot would operate, I think the amount of server resources consumed would be negligible. According to alexa.py, the bot would query Alexa's API and parse XML responses like this one for wikipedia.org, which is only 1.1 kB in size. Multiply that by the 4,560 domains in the candidate list, and the total amount of bandwidth required to download the data for all of the domains in the list is just 5.0 MB. "A subset of these pages will be updated each month." This script would barely consume any resources on a low-end personal computer.

  Responding to Wnt's suggestions, I would prefer to see both the unique visitor and Alexa rank metrics for each website. To be vendor-neutral, it would also be appropriate to use similar statistics from Nielsen, SimilarWeb, and other data providers when available (although I have not looked into whether this data is actually publicly available from these other providers). With multiple providers, I'm not sure how much of this information would belong in the infobox, but the metrics would be worth displaying in a table in the article body.

  GreenC's suggestion to use a module appears to be the best and most versatile method for data storage, although I would prefer to see the metrics updated monthly instead of (bi)annually. — Newslinger talk 08:44, 5 April 2019 (UTC)

  @Newslinger: One of the issues I had with archiving data was that it was impossible to save the API pages in the Wayback Machine, even though it would have been much better to use the API than to save the HTML pages. This now seems to work (even without logging in and using the beta version of Save Page Now). There was a very large amount of overhead associated with archiving the full HTML, although the graph images are useful due to containing data for the past year.

  @Lkolbly: Are the API keys necessary? In my experience, while collecting data from the API (without archiving it), I was able to download data for more than a million websites by making hundreds of concurrent connections and resetting my network's IP address every few minutes. I'm not saying that this would be a good way to do it, but it's certainly... possible. Jc86035 (talk) 09:26, 5 April 2019 (UTC)

  I don't think they're strictly necessary. You don't get as much data (basically just rank and delta, but that's all we show anyway), being who I am I love collecting as much data as I can from everywhere and storing it in text files until I run out of disk space. Resetting my network IP every few minutes would be... inconvenient, for sure. As far as server load goes, Wikipedia currently receives 1.8 edits per second, this would be increasing that by 1.7 milliedits per second (0.1%). Linking to the API page from the citation would be not user friendly for people who did want to click through to the Alexa page, though. Lkolbly (talk) 12:54, 5 April 2019 (UTC)

  @Lkolbly: Perhaps a custom citation could be used to link to both the current HTML and XML pages, as well as the archived XML page?

  With the Lua module approach this could be accomplished with very few edits, as few as one per month (i.e. by updating all of the data at once).

  Incidentally, you might be interested in looking at Module:Alexa, Wikipedia talk:Lua/Archive 6#Alexa template and User talk:Jc86035#Alexa ranks. Jc86035 (talk) 15:53, 5 April 2019 (UTC)

  Since this discussion is in the policy section of the village pump, it might be better to focus on whether Alexa ranks should be included at all, rather than the technical implementation (which would be moot if there is consensus against including Alexa ranks). — Newslinger talk 01:30, 6 April 2019 (UTC)

• Kill Alexa ranks. Wikipedia is an encyclopedia. In case you've never seen an encyclopedia besides Wikipedia, I assure you that they don't have things like current stock value, Alexa ranks, or other information that is constantly in flux. They give you the big picture and point you to other resources for more detailed information. Kaldari (talk) 22:35, 5 April 2019 (UTC)

  @Kaldari: We have plenty of other time-dependent statistics (population, for instance). Alexa ranks aren't inherently unsuitable just because they're updated every day and aren't publicly archived by the company. As noted above, some sort of statistic to indicate the popularity of a website can be of value (though not necessarily just the Alexa rank). Jc86035 (talk) 08:12, 6 April 2019 (UTC)

  Also probably worth noting is that Wikipedia isn't really that similar to a traditional encyclopedia, because it tends to have much more depth and breadth (and, of course, can be updated more easily). Outside of articles about people and buildings, there are definitely a lot of regularly-updated statistics (music charts, passenger numbers, political polls...). Jc86035 (talk) 08:51, 6 April 2019 (UTC)

  I think one question to ask is whether Alexa is a primary or a secondary source. I mean, I know that the ratings come from a Computer, which sits between the seraphim to judge the deeds of men, but it does after all post on little pages that few people read that aren't even archived. If some blasphemer were to come along and say, "the Computer is wrong!", the answer would surely be that Alexa faithfully publishes the result of its Algorithm and therefore cannot be held to blame for following its outcome wherever it leads without question, even if it is "a complicated calculation that involves correcting for biases as well as identifying and discarding fake or spam traffic", as the official guide below puts it. But Wikipedians are a crusty group with a formidable dogma of their own, and I think any delivery of magical stone tablets from a burning table at Wikimania would be attended by protests concerning use of a self-published source. And some of us might read the heresies of those excessive in the faith, noting that there is guide after guide after official guide online about how to improve a site's web rankings by means such as the company installing the Alexa Toolbar on all their browsers in all their computers to start, registering/verifying the site with Alexa, using the Alexa Rank Widget on company pages because "every click will be counted", and all the usual SEO techniques to improve Alexa ratings by subscribing to Alexa's Marketing Stack and Advanced Plan. I should note the importance of search-directed traffic in that, so it is worth noting that readership of the Alexa article increased long term after Template:Alexa was introduced in November 2016. If I were the Computer I would send that Wikipedian a Christmas present, but that's just me. Anyway, I think it is instructive to consider the difference in reaction Wikipedians would have if someone gave each company site a rank based on some human reviewer they found on the internet, even if he wasn't biased and didn't sell services on the side. That's how much more important and dignified by nature the Computer is than any of us... remember it. Wnt (talk) 10:33, 6 April 2019 (UTC)

  @Wnt: Assuming good faith on Alexa's part, presumably those methods would allow them to get more accurate data (although obviously they wouldn't mention that a website's ranking might actually go down if they got more accurate data from that website, since they're trying to sell something). Obviously it's impossible for anyone outside the company to genuinely verify whether their statistics are made-up, but the ranks themselves are usually close to or in agreement with those calculated by other companies.

  On whether Alexa is a primary or secondary source, I would say that Alexa is mostly a primary source since they collected and analyzed their own data in order to publish the ranks (rather than, say, analyzing a public dataset). However, the data has been used in various reliable secondary sources, including the New York Times (2014) and the Guardian (2006). Jc86035 (talk) 18:41, 6 April 2019 (UTC)

  @Wnt: On the page views issue, the increase could also be partly attributed to another bit of Amazon with a similar name becoming increasingly popular around that time. In any case, {{Infobox website}} has had |alexa= for an uninterrupted period beginning on 15 March 2008, and the parameter previously existed as early as 18 September 2006. Furthermore, the creation of the template doesn't mean much on its own; editors would still need to manually add that data (OKBot used to update some of this data from 2011 to 2014). Jc86035 (talk) 19:05, 6 April 2019 (UTC)

• 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?
• The Curious Case Of MomDot.com’s Traffic Stats
• Why can’t marketers see that digital metrics are bullshit?
• Web Stats for musicians: Lies, Damned Lies and Google Analytics.
• Buywebsitetrafficreviews: We know where to buy web 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) 12:11, 6 April 2019 (UTC)

@Guy Macon: All sorts of other minor statistics could be faked and we wouldn't be able to tell; for example, music sales have been faked in the past, but Wikipedia doesn't just write off all of the music charts from the decades where this was an issue.

I think this Guardian article might be somewhat helpful, although it's almost nine years old.

On the pages you've linked: I note that almost all of them are anecdotes and most of the analyses don't seem to be conducted by professionals in the field. While the anecdotes may be somewhat useful, most of them are just from people who run websites, and I don't think any of them mention any filtering of bot/crawler traffic.

• The first is someone's blog, so we can't really use it. The points are, I think, valid; but given the difficulty in collecting the data in the first place, discrepancies are completely expected. The data collection issue is somewhat concerning, although it's worth noting that because none of these companies publish a complete methodology (e.g. how is the data from the Alexa add-ons normalized relative to the data collected directly from the websites?) it's more difficult to tell if Alexa's doing it right. They do, at least, have multiple data sources. Presumably, since their data is (hopefully...) their main product, they do have an interest in keeping the numbers somewhat accurate.
• The second is also someone's blog. I think it's possible that the author is... counting the wrong things (raw traffic instead of unique visitors), but I do think that their perspective is useful here. If anything, this indicates that multiple data sources should be used, sort of like {{Infobox US university ranking}}.
• The third, a forum post from a website owner, is more than ten years old, which is from before some (to my knowledge) significant changes in Alexa's data collection. Some of the points that the author makes are somewhat flawed (e.g. should Alexa actually have excluded iframes if the embedded content was transferred normally as if it were loaded in a separate window? if they were directly measuring the use of the embedded content they might not have been able to tell).
• The fourth is another blog post, from a staffer at an SEO company. They don't mention Alexa at all, but discuss other companies' traffic statistics and compare them to private Google Analytics numbers. I'm somewhat irritated that they measured "most accurate" by calculating the average error without adjusting for the traffic volume for each website and without using the absolute value value of each error (i.e. instead of letting numerically negative errors cancel out positive errors), since it's not like SimilarWeb's estimates were anywhere close to perfect.
• The fifth, another blog post, has a semi-retraction at the end.
• The sixth is a Marketing Week article (or opinion piece?) which doesn't mention Alexa. I agree with the author's points on why these statistics are unreliable. However, the author notes that he and his co-debater actually lost (and "lost badly") the debate which is the subject of the article; and the inability to measure exact data does not necessarily mean that all of the data has to be written off. Wikipedia has hundreds of pages dedicated solely to cataloguing opinion polls for elections, although arguably those are on slightly firmer ground because polling firms usually release detailed methodology and their reports can be more easily re-evaluated by third parties.
• The seventh, another blog post, doesn't mention Alexa, or any other company that publishes traffic estimates. The author's main point is that interaction matters more than page views. I'd say the page is somewhat irrelevant to this particular discussion because the only way Wikipedia would be able to catalogue interaction in a meaningful and scaleable way is by keeping a database of Facebook likes and such, which is another can of worms and would also be flawed in different ways (e.g. because of those Wi-Fi networks that require users to like the venue's Facebook page before proceeding).
• The eighth and last is a review site for websites which sell traffic. Those services' existence doesn't necessarily indicate that we should summarily ignore all web traffic data. The article The New York Times Best Seller list mentions similar issues. If even "the preeminent list of best-selling books in the United States" has these issues, perhaps it's just something that has to be taken into account if anything useful is to be gleaned from this sort of data.

The problem with writing off this sort of data entirely is that it isn't really definitively more or less reliable than other pre-internet datasets that have been published outside scientific journals (e.g. how the Times compiles the [Best Seller] list is a trade secret), and it doesn't make sense to ignore this data when the pre-internet data has been used anyway just because there's nothing better. Jc86035 (talk) 18:41, 6 April 2019 (UTC)

Music sales cannot be easily faked by anyone with a credit card. There is a huge difference between "we try to provide reliable statistics but some people figure out how to cheat" and "there are multiple web pages that will reliably and undetectable make the numbers as big as you want, with prices starting at less than a hundred dollars". --Guy Macon (talk) 19:03, 6 April 2019 (UTC)

@Guy Macon: I agree that the stakes and costs are obviously a little higher in those cases, but it's not necessarily "as big as you want". A rank in the top 10,000, for example, would be much more difficult to fake than a rank in the top 1,000,000. We also don't really know how good those services are. (And it's plausible that several hundred US dollars would be enough to make a difference near the bottom of some music charts, given a cooperative record store manager...)

When I was trying to archive [way too much] Alexa data, I used lists of URLs from a competing service which publishes a list of 1 million domains in order to be able to archive Alexa data. Many of the sites on the other list had almost identical ranks on the Alexa chart, whereas some of the others had Alexa ranks far below 1 million, which indicates that Alexa might have been more capable of filtering out spammy websites. Nevertheless, a rank above 10,000, or even above 50,000, is presumably something to write home about (sorry, Wikinews). Jc86035 (talk) 19:19, 6 April 2019 (UTC)

If the Alexa rank is notable, put it in the article body. We don't need them in every website infobox, IMO. Kaldari (talk) 19:40, 6 April 2019 (UTC)

In the comments above, Jc86035 confuses the criteria for using a source in an article with the criteria for using a source in a talk page discussion. Yes, a blog is not a reliable source for use in an article. But then again, the comments Jc86035 makes and the comments I make on article talk pages are not a reliable source for use in an article. Whether considering a link to a blog someone posts or the words we write on this page, the reader is expected to evaluate the opinion and decide whether it is a compelling argument.

Jc86035 goes on to question my assertion that anyone make the numbers as big as they want, limited only by their budget. I believe that I am correct. I could, for the princely sum of $25, buy compete control of 1,000 computers with 1,000 IP addresses on a botnet, and use them to inflate the Alexa ranking of a website. If Alexa figured out that the 1,000 computers were inflating the ranking (more likely if I used one computer a lot, far less likely if I only used each computer a handful of times) another $25 would by me a fresh set of a thousand computers. $110 would get me 5,000 computers/IPs and $200 would get me 10,000 computers/IPs. It really is that easy, which is why so many people sell pageviews and visitors.

DO NOT VISIT THE FOLLOWING LINKS!! ONE LINK IS CLICKBAIT AND THE OTHER MAKES FUN OF CLICKBAIT!! Don't Click Me #1 Don't Click Me #2 Don't say that I didn't warn you. --Guy Macon (talk) 21:11, 6 April 2019 (UTC)

@Guy Macon: Thanks for your response. I don't think I was confusing the criteria – to my knowledge, there are no established criteria for collecting anecdotal evidence on talk pages(...?), so I wouldn't have been able to confuse them – though I thought it was worth noting whether they would pass as reliable sources.

Returning to the actual purpose of the discussion, I agree that the statistics are far from perfect due to being proprietary and being apparently easy to manipulate. However, I think this would be grounds for establishing minimum criteria for those statistics' use in articles (e.g. something like "at least two data sources ranked the website at 175,000 or above in the past year, or at the website's peak if the website is currently defunct"), rather than disallowing those statistics altogether. We can presume that it's harder to fake higher ranks, and I think it's somewhat more unlikely that already-notable entities would be deliberately inflating their own website usage in this way. Jc86035 (talk) 15:53, 7 April 2019 (UTC)

• I would oppose all use of Alexa ranks -- but, it would be pointless. O3000 (talk) 21:19, 6 April 2019 (UTC)

RfC on disambiguation of TV articles

An RfC has been opened at Wikipedia talk:Naming conventions (television)#RFC: What disambiguation should shows from the United States and United Kingdom use?. Additional participation is welcomed. -- Netoholic @ 18:52, 3 April 2019 (UTC)

RFC: spelling of "organisation"/"organization" in descriptive category names

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

---

Should all Wikipedia categories which use the word "organisation"/"organization" as part of a descriptive name per WP:NDESC be standardized to use the "Z" spelling, i.e. "organization" rather than "organisation"?

Note that this proposal does not apply to proper names, such as Category:International Labour Organization, which should use the name selected per WP:Article titles for the title of the head article. It applies only to the descriptive category titles invented by Wikipedia editors per WP:NDESC, such as Category:Agricultural organizations based in the Caribbean, Category:Organizations established in the 19th century, Category:Religious organizations by faith or belief, Category:Sports organisations of Ireland, and Category:Paramilitary organisations based in the United Kingdom. --BrownHairedGirl (talk) • (contribs) 19:57, 4 April 2019 (UTC)

Extended explanation

This question may sound like trivial pedantry, but Category:Organizations has about ten thousand descriptively-named sub-categories. Those are inconsistently named, and therefore generate a steady stream of renaming proposals at WP:CFD.

Per WP:NCCAT, category names should "follow certain conventions", but there is no clear convention here; no single principle (or even agreed set of principles) defining which spelling to use. This makes the category system hard to use and hard to maintain, because it is difficult to predict which spelling is in use in each case.

Over the years, these categories have been the subject of numerous renaming discussions, and several are open now. Several well-established principles are applied, but they are often fuzzy or conflicting, and they produce varying outcomes depending on the good faith interpretations of the experienced editors involved. Many categories have been renamed multiple times.

1. MOS:TIES recommends that for English-speaking nations, we should use the (formal, not colloquial) English of that nation.
   However,
   • It is often hard to determine which (if any) usage is preferred in any given country
   • There is disagreement about whether the "S" spelling is actually the clearly-preferred option in any national variant of English
2. MOS:RETAIN advocates that the initial version should be retained in the absence of consensus to the contrary.
3. Geography. No policy appears to cover usage in non-English-speaking nations, so editors apply in good faith a variety of well-reasoned principles which produce different outcomes, e.g.
   A/ Countries which are geographically closer to the UK than the US should use the British spelling, and vice-versa
   B/ Commonwealth countries (i.e. the former British Empire) should follow British spelling.
   However
   • Those two principles clash for the many former British colonies in the Americas
   • There is legitimate dispute about the extent to which British usage persists 50 years after independence

These inconsistencies create clashes of principle. If MOS:RETAIN is applied, then each container category ends up with a random assortment of spellings, depending on the choice of the creator.

However, most categories for organisations are intersections of two or more category trees, e.g.* Category:Sports organisations of Iran is an intersection of Category:Organizations by type and Category:Organizations by country.

Taking that example: if we apply MOS:TIES, we get inconsistent titles in Category:Sports organizations by country, e.g. Category:Sports organisations of Mozambique/Category:Sports organizations of the Comoros.

On the other hand, if we apply consistency across Category:Sports organizations by country, that creates inconsistencies with MOS:TIES-derived names for the country categories. e.g. if Category:Sports organisations of Mozambique was renamed to use "Z", then that would clash with the grandparent Category:Organisations based in Mozambique.

In CFD discussions, the main argument for standardisation is that per American and British English spelling differences#-ise,_-ize_(-isation,_-ization), some British usage prefers the "S" spelling, bit there is no overall preference ... and that while the "S" spelling" is unacceptable in American usage, the "Z" spelling is acceptable variant in all countries.

On the other side, arguments against standardisation prioritise MOS:TIES, and assert that "S" is the standard British usage. They note how ENGVAR variations are accepted in other types of category. One example of this is Category:Association football players, whose subcategories variously use "association football players", "footballers" or "soccer players", depending on local usage. --BrownHairedGirl (talk) • (contribs) 19:58, 4 April 2019 (UTC)

Organizations: Discussion/survey

add your comments and/or !votes here"

• Use "z". I'm British, and use both spellings interchangeably. In some parts of the English-speaking world only "z" is correct, but in others both "s" and "z" are correct. I don't know of anywhere where "z" is incorrect. I must add that it's very tiresome that we have to even discuss this, but there are certain editors who seem to like arguing for arguing's sake. Phil Bridger (talk) 20:27, 4 April 2019 (UTC)
• Couldn't category redirects solve tis without renaming anything? If the answer apears to be "no they can't" then I agree with every word of the above comment by Phil Bridger. Beeblebrox (talk) 21:28, 4 April 2019 (UTC)
  • Categories use WP:soft redirects (see Example), unlike e.g. lists which use hard redirects; while these can reduce the problem, they require an extra click. – Fayenatic London 22:15, 4 April 2019 (UTC)

• @Beeblebrox, two years ago I thought that redirects might be a partial solution (with the limitation which @Fayenatic notes), provided that there was a bot to apply them in all instances, on an ongoing basis. So I proposed the bot, at Wikipedia:Bots/Requests for approval/BHGbot 3, and there were so many niggles that I gave up. (The bot was approved for a trial run, but there were strong objections to making it an open-ended task, which is exactly what would be needed for the bot to solve the problem).

That's why I have come around to the view that we should fix the problem at source by abandoning the pretence that British English has such a strong preference for the "s" spelling that we shouldn't use Z in any topic relating to the former British Empire other than in the United States. --BrownHairedGirl (talk) • (contribs) 22:18, 4 April 2019 (UTC)

• Don't standardize. Personally, I use British English with a "z", but I don't think it is good idea to bow to the consistency zealots on this. They'd only find something more serious to worry about. Johnbod (talk) 21:37, 4 April 2019 (UTC)
  • If there is continuing conflict without standardization, "don't standardize" is the wrong solution. There might be some reasonable middle ground toward standardization and away from conflict, but a basic non-vote definitely isn't it. --Izno (talk) 22:11, 4 April 2019 (UTC)
• Use z. I'm British and use "s" in my personal and professional writing, but it is often inconvenient in Wikipedia that the spelling of categories for orgs is unpredictable. Using the Oxford spelling with the "z" is not un-British anyway. We already use the non-French "z" spelling for France (see CFD in 2017 closed by me) and various other countries in Europe/Commonwealth. Let's take it all the way. – Fayenatic London 22:15, 4 April 2019 (UTC)
• Support - organize was good enough for Samuel Johnson and so it is good enough for me (in the UK). The Americans have in this case adhered to correct classical English. Oculi (talk) 22:17, 4 April 2019 (UTC)
• Use z. I agree with the observations of both Phil Bridger and Oculi. And if something is correct everywhere, it ought to take precedence over one national preference. Now the consistency folks can worry about why Category:Television shows by country rolls up to Category:Television programs where "shows" is correct wherever English is used but the spelling of program/programme may differ. Cheers, Carlossuarez46 (talk) 23:33, 4 April 2019 (UTC)
• On the point of commonality, do see MOS:COMMONALITY. --Izno (talk) 23:42, 4 April 2019 (UTC)
• Use "z", since it is considered acceptable in British English (unless I've been doing it wrong all this time). Jc86035 (talk) 09:38, 5 April 2019 (UTC)
• Don't standardise. Continue to use "s" in countries that predominantly use "s" (like the UK, Australia and New Zealand). It's very rare to see "z" in the UK outside Oxford these days. We don't change other category names for consistency, so I have no idea why we'd want to here. It is clear from the media, from previous WP discussions and from usage in WP articles by British editors that "s" is now greatly preferred in the UK. -- Necrothesp (talk) 10:21, 5 April 2019 (UTC)
  • @Necrothesp, your statement that we don't change other category names for consistency is plain false. On the contrary, large numbers of category names are changed for consistency every single day. Most weeks, several hundred categories are renamed for consistency at WP:CFDS per WP:C2B, WP:C2C, or WP:C2D ... while new consistent conventions are repeatedly established at full CFD discussions.

It's also clear that you well know that statement to be false, because you yourself have made plenty of CFDS nominations on the basis of consistency. including [17], [18], [19], [20], [21]. That's only a small sample, and it is very sad to see an admin asserting as fact something which they have demonstrably known for many years to be untrue.

The reason we seek consistency, as you clearly well know, is that inconsistent titling is confusing for both readers and editors. You also do huge numbers of article moves on that very basis per the policy WP:CONSISTENCY (part of WP:Article titles), and as noted above the same principle applies to categories: see WP:NCCAT.

In this case, we have policy on what to do: MOS:COMMONALITY says "For an international encyclopaedia, using vocabulary common to all varieties of English is preferable: Use universally accepted terms rather than those less widely distributed, especially in titles". In this case, the Z spelling is a universally accepted variant, even if it is not universally preferred ... whereas the "S" spelling is not acceptable in American English. --BrownHairedGirl (talk) • (contribs) 12:11, 5 April 2019 (UTC)

You misunderstand me. As usual, it appears. We do not change category titles for consistency in WP:ENGVAR circumstances. We may change them for consistency in non-ENGVAR circumstances if it is uncontroversial, yes. This is a different issue. And despite claims to the contrary, this is an ENGVAR issue, as "z" is indeed very rarely used these days in British English. -- Necrothesp (talk) 12:54, 5 April 2019 (UTC)

No, Necrothesp, I did not misunderstand you. I correctly understood the clear meaning of what you actually wrote, which now turns out to be radically different from what you now claim you intended to say. Please do not misrepresent your change of assertion as someone else's failure to understand.

As to ENGVAR, for over a century the leading dictionary of British English has been the Oxford English Dictionary, which continues to recommend the "Z" spelling as the preferred form. Are you really, seriously, trying to claim that OED's recommendation is not an acceptable usage in British English? Really? --BrownHairedGirl (talk) • (contribs) 13:09, 5 April 2019 (UTC)

@BrownHairedGirl, FWIW the OED is now the last part of Oxford clinging on to Oxford spelling; even Oxford University itself has deprecated its use ‑ Iridescent 22:36, 5 April 2019 (UTC)

• Our present policy wastes a great deal of editors' time and effort. It doesn't produce consistent results. Consistency in country subcategories is achieved at the expense of inconsistency in all the other hierarchies. Consistency would increase our efficiency and enable us to quibble about things that are more important. There is nowhere where spelling organization with a z is wrong. The problem really is that in the UK it is seen, quite mistakenly, as American linguistic imperialism.Rathfelder (talk) 12:40, 5 April 2019 (UTC)
  • No, it's merely seen as uncommon in the present day. An archaic usage preserved by Oxford but not much elsewhere. -- Necrothesp (talk) 12:57, 5 April 2019 (UTC)
• Support "z" - Barring specific cases where a proper name using "Organisation" is involved, the more inclusive "organization" should be used in all other cases. It is clear that this has been an ongoing issue that repeatedly comes up and it will save everyone's time in the long run to make this a standard convention. The fact that one spelling ("z") is acceptable (if not preferred) globally and the other is unacceptable in large parts of the world makes this change an obviously better convention over the current hodge-podge of MOS:RETAIN-based random spellings or multiple CFDs to attempt to meet MOS:TIES. I think BrownHairedGirl has made a very compelling argument and I haven't (yet?) seen any substantive argument against it. - Paul^T+/_C 14:11, 5 April 2019 (UTC)
• Don't standarise per Necrothesp. There's no reason to change the status quo here, and Oxford is not an authority for the whole of British English (and definitely isn't for Australian or New Zealand English, where -ise is strongly preferred). Iffy★Chat -- 14:30, 5 April 2019 (UTC)
  • Also, this is NOT a commonality issue, many parts of the world primarily use 's', just as much as many areas use 'z'. This isn't the American english Wikipedia, it's the English language wikipedia for all users of the English language. Iffy★Chat -- 08:23, 8 April 2019 (UTC)
• Slightly alternate proposal: Use "z" but create a preference setting where editors who want to see the word spelled with an "s" in category names can see it that way. bd2412 T 14:54, 5 April 2019 (UTC)

• @BD2412 I appreciate the quest for a solution which gives as many people as possible most of what they want. That's a good approach throughout life.

So I have no objection in principle to that idea, but is it technically feasible? I know that much wizardry can be achieved by AJAX, but even if some cunning code could change the displayed spelling of category titles as they appear at the bottom of an article or at the top of a category page, how would it distinguish between descriptive titles and proper names, so that it converted Category:Sports organizations of Estonia but not Category:International Labour Organization or Category:Organization of American States?

Readers might like this, but it would cause problems for editors, who would never see the actual title of the category, and be mystified why tyoing in the "S" spelling produced a redlink. --BrownHairedGirl (talk) • (contribs) 15:23, 5 April 2019 (UTC)

My initial thoughts on this would be that 1) some kind of tag would need to be put on formal names to prevent them from showing up with the "s" spelling, if we care to do that, and 2) irrespective of the outcome of this discussion, there should be a category redirect pointing from the "s" spelling to the "z" spelling. When using hotcat, at least, this will change the input to the correct category. bd2412 T 15:36, 5 April 2019 (UTC)

So who gets the job of tagging all the relevant categories, and maintaining those tags? As the Pages per ActiveEditor ratio continues to grow, we need fewer of those maintenance tasks, not more.

As to redirects, yes I agree. As I noted above in reply to Beeblebrox, I tried two years ago to create a bot to do just that, but the BRFA got drowned in nitpicking so I gave up.

I do think that Phil Bridger's reminder of the fate of the time/date preference thing is worth remembering. It was all just seen as too much complexity for too little benefit. --BrownHairedGirl (talk) • (contribs) 16:52, 5 April 2019 (UTC)

Before going too far with that proposal I would remind editors that we used to do something similar with dates in articles, where they were presented in dmy or mdy format in accordance with a preference. That system was done away with - here is one discussion but I'm sure there were more - for reasons that could also be applicable to this proposal. Phil Bridger (talk) 15:59, 5 April 2019 (UTC)

• Use 'z' except in countries where 'z' is plain wrong (perhaps Australia and New Zealand?). Marcocapelle (talk) 16:36, 5 April 2019 (UTC)
• Support "z" I do a lot of work on organizational categories. Our present policy wastes a lot of my time and energy. It prioritises consistency by country over consistency by subject, for no obvious reason, even where English is not a native language in the country concerned. Personally I have been using s for about 55 years, even though I was brought up to revere the Oxford English Dictionary, but I think the importance of consistency should outweigh personal preference I . Rathfelder (talk) 17:26, 5 April 2019 (UTC)
• Oppose standardisation z these days is a variant, not the standard modern spelling in British English with the OED and related publishing house very much fighting a losing battle on this. In other countries z is used even less. Whatever is done there will be inconsistency as there are numerous main articles and lists using s, to say nothing of other cases where different spellings and terms are in use (programmes/programs/shows has already come up) so trying to impose a global consistency just isn't going settle things. Timrollpickering (Talk) 18:14, 5 April 2019 (UTC)
• Use “z” per MOS:COMMONALITY, Z would be preferred because it is accepted intenationally and S is not. —pythoncoder (talk | contribs) 19:30, 5 April 2019 (UTC)
• Use "z" Standardization helps, it's categorization. It is WP:COMMONSENSE to use what's more common. --QEDK (後 ☕ 桜) 20:06, 5 April 2019 (UTC)
• Don't standardise. I don't see this as a problem, and "z" is not acceptable in Australian (or I presume NZ) English. Frickeg (talk) 21:29, 5 April 2019 (UTC)
  • @Frickeg, do you have any actual evidence that the "Z" spelling is not an acceptable variation in Australian English? Sorry to be a where's-the-WP:RS pedant, but in countless CFD discussions I have seen many confident assertions of national preferences in spelling, but there is almost never any evidence offered. Please can you fill the gap, and be the one who actually provides the sources which support your claim that "Z" spelling is never an acceptable variation in Australia? Thanks. --BrownHairedGirl (talk) • (contribs) 22:02, 5 April 2019 (UTC)
    • The Macquarie Dictionary, the closest thing to an authority here, says (paywalled) "Current Australian usage clearly favours consistent use of -ise". Although Macquarie does list "-ize" as a variant (perhaps "not acceptable" was an overstatement, but "very rarely used" is certainly true; Macquarie also lists practically all US spellings as variants, which doesn't mean they're generally acceptable in AusEng), I have been unable to find a single Australian style guide that allows "-ize", and you will practically never see it in Australian publications. It is clearly recognised as an Americanism, and even if there is some doubt about the common British usage, there really isn't for us. I see no reason why WP:TIES would not apply, and WP:RETAIN when we are talking multi-national categories. Frickeg (talk) 23:38, 5 April 2019 (UTC)

• Thanks @Frickeg. Would you be ale to quote the rest of the entry? The actual wording is important to the application of MOS:COMMONALITY, and your paraphrasing raises a few questions for me.

As to WP:RETAIN, it is a disastrous principle to apply to any category set and esp large sets, because it produces random outcomes across category trees. That makes it hard for editors to add categories, hard for readers to type them, and massively complicates all sorts of maintenance and templating functions. That's why so many categories of all types are renamed very day per WP:C2C. --BrownHairedGirl (talk) • (contribs) 00:43, 6 April 2019 (UTC)

• The entirety of the entry "-ise": "a suffix of verbs having the following senses: 1. intransitively, of following some line of action, practice, policy, etc., as in Atticise, apologise, economise, theorise, tyrannise, or of becoming (as indicated), as crystallise and oxidise (intr.), and 2. transitively, of acting towards or upon, treating, or affecting in a particular way, as in baptise, colonise, or of making or rendering (as indicated), as in civilise, legalise. Compare -ism, -ist. Also, -ize. [from (often directly) Greek -izein. Compare French -iser, German -isieren, etc.] Usage: -ize is the usual spelling in US English. In Britain there is some variety: some publishers standardise on -ize, but others use -ise. Attempts to distinguish -ize in words based on Greek (idolize, monopolize) from -ise in words that have come to English from or through French (realise, moralise) founder on the difficulties of knowing the precise history of many words. Current Australian usage clearly favours consistent use of -ise, a practice which has the advantage of being easy to remember." Frickeg (talk) 03:20, 6 April 2019 (UTC)

• Many thanks, @Frickeg. That's a clear recommendation of "ise", but not an outright deprecation of "ize". That would certainly support using "organisation" in articles ... but in category titles, which are navigational devices rather than enyclopedic content, it seems to me that MOS:COMMONALITY justifies using the non-preferred spelling. This isn't a petrol/gasoline issue, where one usage is clearly deprecated. --BrownHairedGirl (talk) • (contribs) 21:10, 6 April 2019 (UTC)

• Use "z" - Just for fun, I did a survey of usage on Belizean news sites. Belize is a Commonwealth country, but geographically close to the U.S. I expected usage to be about even, but usage of "organization" was 34 times higher than "organisation"! I would be OK with leaving a specific exception for UK-related categories, but overall it seems like "organization" is the more internationally-prominent spelling. Kaldari (talk) 22:27, 5 April 2019 (UTC)
• Alternate Proposal - use z for all categories except in the country where s is the clear choice - and I'd suggest a discrete list be created of these (UK, NZ, Australia are primary). This will at least shrink the issue - where it's an either/or, or any of these geographical proximity cases, they default to z. It won't quite resolve the issue, but I think it's an improvement that will avoid most of the likely blowback from fellow s-speakers. Nosebagbear (talk) 22:46, 5 April 2019 (UTC)

• @Nosebagbear, I'd very much prefer simple standardisation, but I think that your proposal could provide some limited improvement if this RFC agreed an actual list of which countries fall into that category. Without that definitive list, we would effectively have no change; we would still face the same CFD debates over and over again about which if any is the preferred usage in Ruritania (see e.g. the CFR debate on Organizations based in Oman). I appreciate what you are trying to achieve by changing the default, but it still risks an ongoing saga of many dozens of case-by-case debates. So I think that proposal would have more chance of meaningful assessment if there was some actual evidence for the claimed clear preference for "S" usage in NZ+Australia, and in any other country which editors want to list. As I note above, these discussions are overwhelmingly dominated by assertions rather than evidence, but the sincere indignation which often accompanies the objections is nearly always unevidenced. --BrownHairedGirl (talk) • (contribs) 23:42, 5 April 2019 (UTC)

• Use z unless the content categorized is predominantly using s. That is, default to z which is acceptable in every ENGVAR, but retain s for local WP:CONSISTENCY if all or most articles in the category are non-North American and (not "or") are also using the s spellings in their content and (where applicable) titles. E.g., a "Category:Animal rights organisations in England" category should likely not move to the z spelling, but "Category:Animal rights organisations" certainly should be (and is) at Category:Animal rights organizations, for MOS:COMMONALITY reasons. The z spelling is preferred even in British academic writing (and an encyclopedia is basically academic writing), so z is a sensible default for multiple reasons.  — SMcCandlish ☏ ¢ 😼  00:50, 6 April 2019 (UTC)

I see several problems with that:

1. It would lead to inconsistencies within the category tree for each country, which would be even worse than the current mess
2. It would make category titles unstable, because as articles are created or deleted or recategorised the balance would change
3. Assessing it would require a lot of editor time, but editor time is increasingly scarce: the ratio of articles per active editor is almost 4 time what it in 2007, and participation in CFD discussions is at ~5—15% of the levels in 2006. There is a persistent, multi-month backlog of CFD closures. However nice it might theoretically be to have such fine-grained decisions, we simply don't have the resources to sustain them.

We need a simple solution which creates stable outcomes, and where mistitled pages can be identified with the help of tools such as AWB and Petscan. --BrownHairedGirl (talk) • (contribs) 01:54, 6 April 2019 (UTC)

I don't see 1 as a real problem. There will always be inconsistencies, unless Oxford/Harvard spelling is made mandatory on Wikipedia for everything, which isn't going to happen (though it's a proposal I would support for the same reason I supported MOS:JR getting rid of the comma that some older Americans still prefer). Not concerned about 2, either. It's already a criterion (a speedy one, in fact) that category names are to align with article names, so it's already just a fact that they'll shift over time as the mainspace content changes; this is a dynamic site. But the rate of change of s/z stuff is barely detectable, anyway, so there's not really much potential for churn. I'm not sure how much editor time would be consumed, per point 3, but it's something we already do at CfD anyway, about lots of things. It only consumes the time of editors who choose to spend a lot of it at CfD, like you and I do, and we're pretty good at recognizing patterns and getting on with our !votes. If we had a rule like this, it should produce one outburst of category renaming activity, then remarkable stability after that: defaulting to z, unless there's a compelling and demonstrable reason to use s for a particular case. I'm "optimizing for the probable rather than the possible" here; there is no limit in the imagination to what could be possible, but we know from experience that most British topics, for example, are going to use the s spelling, so we can already predict how British-specific categories are going to be spelled. If we default to z for stuff with no national tie, then we can also predict how the majority of categories will be spelled, absent some overwhelming cluster of s-titled articles within one.  — SMcCandlish ☏ ¢ 😼  01:41, 14 April 2019 (UTC)

• Use "z" - Our categorization system should not be a endless battleground for nationalistic emotions or editorial ownership, but to serve as an internal system by which we order pages. As such, having a consistent style which makes life easier (and faster) for readers and editors, and will save time wasted in category discussions, is much better goal than any variation of the current system. Also editor supporter statements above me. --Gonnym (talk) 19:51, 6 April 2019 (UTC)
• Use "zed" (or "zee" if you like) As a bit of a traditional Brit, I support Oxford spelling which prescribes -ize endings and hence avoids transatlantic conflict. Not sure on Australian / New Zealand / Indian usage though. Greenshed (talk) 20:02, 6 April 2019 (UTC)
• Use "z" – Though "s" may be more common in the UK, that's like 60 million people compared to 1.5 billion English speakers. Z is more global, used either primarily or as an acceptable variant in almost all if not all English-speaking countries. Standardization is a good idea for consistency, readability, searchability, and reducing the needless category renaming. Leviv ich 22:07, 6 April 2019 (UTC)
  • India, Australia and New Zealand all use 's' primarily, and so do most English speakers in Europe and Africa, It's not just Britain. Iffy★Chat -- 08:23, 8 April 2019 (UTC)
    • @Iffy, do you have any actual evidence from reliable sources to support your assertion that most English speakers in Europe and Africa use 's' primarily? I don't mean some cherrypicked example, but some evidence of the claimed pattern of usage. --BrownHairedGirl (talk) • (contribs) 09:21, 8 April 2019 (UTC)
• Use "z". When I use HotCat to put articles in categories it is a nuisance to have two seperate alphabetical lists. And my copy of the Collins Paperback German Dictionary, 1988 edition, only lists Organization in the English side. It tells me that Organisation is the German spelling. Bigwig7 (talk) 12:21, 7 April 2019 (UTC)
• Use only one, this is a direct presentation to readers, so having 2 content categories for a spelling variant isn't useful. I prefer the "z" option slightly, as there seem to be more sources with that variant. — xaosflux ^Talk 18:59, 7 April 2019 (UTC)
  • This isn't about having 2 sets of categories for the 2 different spellings, it's about how the categories should be spelled. Iffy★Chat -- 08:23, 8 April 2019 (UTC)
    • As long as we don't have competing Category:Cat organizations and Category:Cat organisations, I don't care too much so long as all of the articles about the content are in the same one, (e.g. Cats USA, Cats Canada, Cats Australia, Cats UK) should all be in only one of those, regardless of the ENGVAR used in their article. — xaosflux ^Talk 14:13, 8 April 2019 (UTC)
• Mostly use "z" - except for English-speaking countries where "s" is more common, use "z" everywhere. It's more intuitive, although this doesn't override the ENGVAR principle to use the local spelling. עוד מישהו Od Mishehu 15:22, 8 April 2019 (UTC)
• Standardise on "z", with the exception for names involving "s". I'm normally one for letting people use whatever spelling they feel is appropriate, but this seems like a reasonable case for standardisation, and as noted, there are very few contexts in which "z" is actively wrong rather than merely not-preferred. Andrew Gray (talk) 19:07, 8 April 2019 (UTC)
• Use "z", except in official names of organisations (sic). My initial idea was to use "z" for all non-specific categories and "s" for categories specific to regions that use that spelling, but it might be too hard to determine for non-English-speaking countries. We'd waste a lot of time arguing over individual countries, like Russia where usage can be quite split. -- King of ♥ ♦ ♣ ♠ 04:40, 9 April 2019 (UTC)
• Z per many good !votes above, starting with Phil Bridger. Jonathunder (talk) 20:33, 9 April 2019 (UTC)
• Use "z" When it comes to global categories like this standardization is far more important than ENGVAR. And I say that as one who has always spelled organisations with an S. Harry Boardman (talk) 13:06, 12 April 2019 (UTC)
• Use "z", except when referring to a proper name. A convincing cost benefit case has be made for more uniform and predictable categories. A Google comparison of hits for the two spellings shows a 76% dominance for the Z spelling, and I came across a graph showing that Z is dominant in the UK by a 2-to-1 ratio and apparently increasing. Australians and some others may not be happy, but they surely are familiar with the predominate US/UK spelling. At least they will find that Wikipedia consistently has the "wrong" spelling, rather than having to deal with it being chaotically wrong. Alsee (talk) 14:32, 12 April 2019 (UTC)
• Do not enforce spelling. "ize" endings are not acceptable in New Zealand English, and Wikipedia is never going to be 100% consistent (unless we throw out WP:TIES and WP:ENGVAR, which is way beyond the scope of this proposal).-gadfium 03:42, 13 April 2019 (UTC)

  Can you produce evidence that "ize" endings are not acceptable in New Zealand English? Rathfelder (talk) 12:48, 13 April 2019 (UTC)

  I'll bet money the answer is "no". NZ doesn't have any NZ-specific style guides from a reputable publisher. NZ writers follow British style guides, like almost everyone in the rest of the Commonwealth, aside from Canada. Even Australia does (the government-published style guide is obsolete and generally ignored, and the Cambridge style guide for .au is simply the British one with some Australian vocabulary added, and Oxford doesn't make one for .au in particular, nor does any other publisher we'd care about).  — SMcCandlish ☏ ¢ 😼  01:46, 14 April 2019 (UTC)

• Wikipedia:Manual of Style doesnt really help in this discussion. It's directed at articles, not categories. Rathfelder (talk) 12:48, 13 April 2019 (UTC)
• Support a common-sense standardization that will free up editor time for more important things. MB 15:54, 13 April 2019 (UTC)
• Use "z". I agree with OP arguments, and find opposing comments ineffective. Years back, the article Theater (Amer Eng) was moved to Theatre (Brit Eng) based on the fact that Americans sometimes spell it the British way, so MOS:COMMONALITY overrides RETAIN. The same argument is works here: Americans use only one spelling, but British use both, undermining any TIES argument. RETAIN is a fall-back position used when nothing else can reach consensus. Now, in all the many thousands of categories, I suspect there may be a very few specific exceptions that can be made, but I believe that for "Organization", COMMONALITY trumps RETAIN, and these should all use "z" to avoid the great majority of pointless future category spelling discussions, and let a new separate special discussion/RFC can started for the very few that somehow "must" use "s". --A D Monroe III^(talk) 17:16, 13 April 2019 (UTC)
• It's possible that in New Zealand, or some other part of the English-speaking world, "z" is regarded as incorrect, but is anyone really offended by its use? I, as a Brit, do not get offended when I read an Indian or American book in English that doesn't always use the same grammar or spelling that I use myself, but simply, if I notice it at all, treat it as part of life's rich tapestry. Surely we have more important things to concern ourselves about? Phil Bridger (talk) 17:50, 13 April 2019 (UTC)
• Oppose per WP:CREEP, WP:ENGVAR and MOS:TIES. The category system is broken and needs replacing with a more sensible system of attributes which can be combined freely rather than being constrained into an arbitrary tree. A better system would provide for synonyms and that's a better way of handling such variation. I'd expect this to emerge as WikiData becomes more established and we can then discard the categories. Andrew D. (talk) 22:15, 14 April 2019 (UTC)
• Use "z" - "z" is accepted almost everywhere. When categorizing articles, it's tiresome to guess which spelling a specific category uses. Standardization to the most common spelling is the best solution. -Zanhe (talk) 23:18, 14 April 2019 (UTC)
• Oppose - WP:CREEP, WP:ENGVAR and MOS:TIES are pretty clear in this regard. Unless we're going to go down the same route Wikidata have taken - treating US English and UK English as different languages, and therefore setting up a whole new Wikipedia project for one or other of them, then let's continue to be inclusive and stick to the existing guidelines. WaggersTALK 11:43, 15 April 2019 (UTC)

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

Hastily replying "Not done" to edit requests

Looking through edit requests on pages like Talk:Logic (musician), I've noticed that several editors respond with "Not done" even when they would be able to fulfill the edit request given a little extra information. Sometimes, when a user gives a fairly precise description of what changes they want made, their edit request is rejected for want of reliable sources. The respondent doesn't try to help them find those sources. UI-wise, the red "not done" icons are intimidating as they resemble warning signs. I think this practice is BITEy and would have discouraged me from making further edit requests long ago.

I understand that the Done/Not done templates are part of canned responses provided by e.g. {{ESp}}. (I have never used this template when responding to edit requests myself.) Can we change some of the canned responses to something like "More information needed" with a blue icon, as appropriate? Qzekrom 💬 ^they_them 13:08, 5 April 2019 (UTC)

@Qzekrom: I think this is a good idea, even if almost none of those users will come back (most of them are there because they clicked on the button).

You could test this in the template sandbox, although I'm not totally sure if just making an edit request to implement changes would be appropriate in this case. Jc86035 (talk) 14:08, 5 April 2019 (UTC)

@Jc86035: I like that idea. I can edit the template itself as I am autoconfirmed, but I want to gain consensus here first. Qzekrom 💬 ^they_them 14:43, 5 April 2019 (UTC)

This is a good idea with little to no drawbacks. If anything, an edit request with "more information needed" could be left "open" for a week, and closed after that. Tools should ping users to let them know they are being asked to provide more information too. Headbomb {t · c · p · b} 14:48, 5 April 2019 (UTC)

I would actually prefer if there was a standard number of days an unfulfilled request was left open. If someone responding can't do what the requester desires, there's no harm in leaving it for someone else. 1 week does not seem unreasonable. Even if the OP has left some work for the responder to do (like dig up sources, etc.) I see no reason to close the request so early. If the responder doesn't feel they are up to the task, then let someone else try. --Jayron32 14:52, 5 April 2019 (UTC)

@Headbomb: Yes! Edit requests shouldn't be limited to the binary states "answered"/"unanswered", since characterizing an edit request that has a response but is incomplete as "answered" is misleading. How about three states—open, in progress, closed (cf. GitHub issues)? Qzekrom 💬 ^they_them 15:18, 5 April 2019 (UTC)

(edit conflict) @Jayron32 and Headbomb: I think the problem partially stems from most IPs ignoring the big box that says to ask for something specific. Under the current convention (for lack of a better word, since Wikipedia:Edit requests is not a guideline), all requests which would require any significant effort on the part of the respondent are supposed to be declined. (That IPs can't receive notifications doesn't help.) Perhaps broadening the process – e.g. so that |answered= has a third option for asking someone else to do the work – would be appropriate. Jc86035 (talk) 15:26, 5 April 2019 (UTC)

Well, the thing is, there are two issues. First, of course, is where the requester leaves the template blank, so they don't ask for anything, or alternately where what they ask for is plainly goofing off, or not serious, or gibberish. That should be closed without a response. However, when the person making the request makes a good faith request for a change to an article, the first person to show up and see the request shouldn't instantly close it if they find fulfilling the request too onerous or not worth their time, or too hard to do, or requiring too much work. Good faith requests for an edit should be either left alone or completed, at least for a reasonable amount of time (like 1 week). Any request still open after a week can be closed with a pro forma "Sorry, there was nothing wrong with your request, it's just that no one felt like dealing with it" sort of response. It's the edit requests that get closed with some form of "Sorry, can't be bothered" within minutes. I get that some requests require some work to do; but some people like doing that work, and when people close good faith requests because they are something more complex than a spelling mistake, that presumes that the next guy to come along wouldn't want to or be able to respond to this. Too many edit requests are closed too fast. That's the issue. --Jayron32 16:02, 5 April 2019 (UTC)

@Jayron32: I always understood that the process was strictly only for specific requests like "change X to Y" or "add this exact text to the article". "I can't be bothered" is currently the correct response, because the person requesting that the change be made is supposed to put in that effort (you might want to read Wikipedia:Edit requests if you haven't already). Even if some editors do put in the work to complete those requests, they aren't expected to under the actual conventions of the process.

I think this is probably at least in part because of the "anyone can edit" philosophy, which doesn't necessarily work that well in practice. Jc86035 (talk) 16:34, 5 April 2019 (UTC)

"Is" is not a synonym for "should be". Whatever is being done, for whatever reason, has nothing to do with what should be done. --Jayron32 16:41, 5 April 2019 (UTC)

I mostly process 'technical' edit requests - if the edit isn't clear, I usually deactivate it and leave a note for the requester to work up the change in a sandbox first. As far as this being a "policy" discussion though, are you trying to create or alter a specific policy here @Qzekrom:? Wikipedia:Edit requests is specifically marked as "not" a policy or guideline. — xaosflux ^Talk 14:56, 5 April 2019 (UTC)

@Xaosflux: I think there should be a guideline for responding to edit requests stating that responses should be friendly and non-BITEy. Changing the response template would help to implement that. Qzekrom 💬 ^they_them 15:12, 5 April 2019 (UTC)

@Qzekrom: I don't think any policy or guideline change would be necessary for modifying the template, since a change to the template to make it friendlier would be in line with Wikipedia:Please do not bite the newcomers, which is already a guideline. Jc86035 (talk) 15:26, 5 April 2019 (UTC)

@Xaosflux: Fair enough. Qzekrom 💬 ^they_them 15:28, 5 April 2019 (UTC)

Being friendly is a good idea, and at the least if we "deactivate" an ER without completing it, adding specific information to the requester is useful (obv not needed for when there are non-er er's like empty ones) - but for most of these it should be clear that ER's are not meant to be a "suggestion box" - they are meant to be a check against the protection policy. Ideally no articles would be protected, and noone would make bad edits - but obviously that is a pipe dream; so ER's serve as a way to allow for improvements when pages are protected. If we really want a "suggestion box" function, it should be tracked in another manner. — xaosflux ^Talk 15:30, 5 April 2019 (UTC)

If so, the 'closed' status could still be |answered=?, with a twinkle/script/whatever message be ' Additional information needed', rather than ' Not done'. Some of the required changes would need to be done at Module:Protected edit request. I don't know about the scripts involved though. Headbomb {t · c · p · b} 15:36, 5 April 2019 (UTC)

(edit conflict) @Xaosflux: I don't think a different process altogether would be as helpful. The interface for unregistered users would be made more confusing if there were both "edit request" and "suggest an improvement" buttons on protected pages. Having a time-limited (e.g. extra parameter with value being the timestamp, template turns from big notice to smaller notice and is recategorized after seven days) and centrally tracked system for this would seem useful, although maybe this would just end up being the same as (or possibly a mildly improved version of) the article feedback tool. Jc86035 (talk) 15:42, 5 April 2019 (UTC)

{ec}} @Jc86035: We could perhaps modify the template {{edit semi-protected}} to have an additional status for answered= - this would mean it stays the same for the requester, but instead of just on/off for the responders it could be on/off/(something else). The (something else) could be for more general discussions and not pollute Category:Wikipedia semi-protected edit requests with edits that are not ready-to-go? — xaosflux ^Talk 15:59, 5 April 2019 (UTC)

​@Xaosflux: Perhaps "Wikipedia semi-protected edit requests in progress"? I think this would require some other things:

• An RFC, if the issue is potentially contentious
• Changes to AnomieBOT (since it generates lists of edit requests)
• Changes to the relevant templates, edit notices and information pages (I don't think Twinkle has any related functions, but maybe other scripts might)
• MassMessage to users who have recently marked edit requests as not done, informing them of changes to the template
• Creation of a category for older "in-progress" edit requests, if the existing categories become too large
• Creation of a parallel "process" (i.e. categories, template code and edit notices) for edit requests to unprotected pages?

At that point it might also be useful to test whether making a "suggest improvement" button more visible (i.e. before the user goes to an article's edit window) results in any useful feedback, perhaps in conjunction with WMF staff. Jc86035 (talk) 16:23, 5 April 2019 (UTC)

Keep in mind, this isn't just done for articles. Plenty of edit requests are made at templates and modules with a "please implement this feature" by editors don't know how to code things themselves. You might argue this is a misuse of the template, but a "more information needed" closure would be much better than "No, code it for us first, you lamer!" closure Headbomb {t · c · p · b} 16:40, 5 April 2019 (UTC)

I have been thinking about this issue some also. What I would like to see actually is a more rich |answered= set of parameters (not just ? but more like "needs consensus"/"no details", which would categorize accordingly and deactivate the request) and softer language/iconography in the responses. I distinctly do not want an "in progress" indicator. That has low utility. As for technical edit requests, see also WT:TFD##RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions. --Izno (talk) 16:48, 5 April 2019 (UTC)

Don't forget to update WP:EPH. That's what most user's use to answer edit requests and place Done/Not done templates. 125.63.105.110 (talk) 15:24, 9 April 2019 (UTC)

My understanding of the purpose of edit requests is as follows. They allow knowledgeable unregistered editors to edit protected articles, doing all the work except the actual edit. I'm opposed to changing that, at least without wide community participation and consensus. i.e. a max-exposure RfC. We have other avenues for mentoring and newbie assistance. The reason there are so many "not dones" is because so many users follow our easy navigation to the edit request facility without reading even the information put in front of them during that process, let alone WP:Edit requests, and are therefore misusing the process because we make it so easy for them to do so. ―Mandruss ☎ 16:43, 9 April 2019 (UTC)

This does this need a RFC. Any time restriction should not apply to requests that don't actually make a request and to those where the IP simply copies the entire article to the talk page. Both of these happen more often than you would think. MarnetteD|Talk 16:48, 9 April 2019 (UTC)

Then maybe we need to make it just as easy to ask for help in the "correct" way as it is to make an edit request. Phil Bridger (talk) 17:05, 9 April 2019 (UTC)

WP:AGF is not a suicide pact. Both of my examples are all too often simply trolling. What easy or correct way to ask are you talking about. MarnetteD|Talk 18:44, 9 April 2019 (UTC)

I assumed that was a reply to my comment made by an editor who understands and follows WP:THREAD. ―Mandruss ☎ 18:49, 9 April 2019 (UTC)

Yes, it was. Phil Bridger (talk) 19:12, 9 April 2019 (UTC)

Yes, I agree that the edit request system is not meant for such things. All I was saying in my reply to Mandruss was that editors who need help should be able to get it easily by other means. Phil Bridger (talk) 19:12, 9 April 2019 (UTC)

(edit conflict) To put it another way no matter how you change the edit request system you are still going to get requests with no actual request or those where all the IP does is copy the entire article to the talk page. There is no earthly reason to wait seven days to respond to - or remove - those from the talk page. MarnetteD|Talk 18:51, 9 April 2019 (UTC)

As a WP:Template editor who fairly regularly responds to editprotected requests, I support this idea, in some form or another. I detest flippant, robotic "not done" responses so much I never use them with others unless the request is toward the WP:BOLLOCKS side. I just manually explain why something has not been done yet, or should not be done unless there's a strong show of consensus for the change, or is a request that can't really be parsed and needs to be rewritten, or seems like a reasonable idea but has not been sandboxed, or .... Using a "Not done" implies some kind of "ruling" that the request cannot proceed, when it's more often "I don't understand", "I don't care", "I don't see a discussion about this", etc., and should have simply either been left open for someone else to deal with, or responded to with something more useful, like a request for more information. I've even taken some other TEs to task on their user talk page for responding with "Not done" to requests that should have been done, in cases where it was clear that that request was rejected out of lack of interest or time or understanding, not lack of the request having sufficient merits.  — SMcCandlish ☏ ¢ 😼  01:53, 14 April 2019 (UTC)

I have no objection to any editor using a kinder, gentler template instead of {{not done}}. Perhaps it will catch on, perhaps not, but we can't mandate it. While any editor is free to assist and pamper clueless readers to whatever degree they desire, it must remain completely optional. In my experience most of these bad edit requests don't come from people who would invest the time to become competent editors if only we were less bitey, but rather from readers who want knowledgeable editors to work for them on an ad hoc basis. That's not what edit requests are for, and it's not what I signed up for. If anyone wants to propose a WP:Editing services function with voluntary participation, I suggest doing that at WP:VPR after testing the water at WP:VPI. ―Mandruss ☎ 12:39, 14 April 2019 (UTC)

I think we mostly just need a (template/interface) editor to make the changes to enable this from a responder point of view. Once editors have access to the other options, I doubt many will default to the harsher "not done". --Izno (talk) 23:03, 14 April 2019 (UTC)

Featured templates?

Hi, I just was searching for WP:Featured templates on the system, but found nothing! May the question be repetitious; but I am eager to find an answer on the topic. Like featured articles (and good articles), featured lists, featured portals, etc, may the "featured templates" topic will be created someday, or a poll for creating it will be set? I am looking forward the users' ideas on the subject. Thanks, Hamid Hassani (talk) 09:54, 7 April 2019 (UTC)

I can think of a few that should be, but they are Module: space. For wiki templates themselves, I dunno, it would be like an ugly dog contest :) -- GreenC 16:17, 7 April 2019 (UTC)

GA and FA follow relevant MoS guidelines, but there aren't really any for templates or modules. I think it is pointless to introduce a FT system for templates, before there are any standards those templates need to follow. --Gonnym (talk) 16:23, 7 April 2019 (UTC)

Not to mention that we've been systematically reducing, not increasing, the number of "Featured foo" categories on Wikipedia, which is why Featured Portals and Featured Sounds are no longer with us, and that running a Featured Anything progress is an extremely time-consuming process. (Since in the Wikipedia context "Featured" means "eligible for featuring on the main page as an example to readers of Wikipedia's best work", the mind boggles as to what you're expecting to do with this; we can hardly run "today's featured template is {{uw-color3}}" alongside In The News and On This Day.) ‑ Iridescent 16:31, 7 April 2019 (UTC)

Hardly the reason we don't have Featured Sounds! Adam Cuerden ^(talk)_{Has about 6.5% of all FPs} 00:24, 8 April 2019 (UTC)

I could see a Featured Template system as a way to promote better coding practices in en.wiki by identifying templates which follow correct template and accessibility guidelines, correct code conventions, fully documented, etc. Unlike the article system which is reader-facing, this system will be an internal one meant for editors. --Gonnym (talk) 16:36, 7 April 2019 (UTC)

Mother of God, spare us. I beseech you. --BrownHairedGirl (talk) • (contribs) 17:46, 7 April 2019 (UTC)

• Hey, it would be great to have a template/module equivalent for the International Obfuscated C Code Contest. Johnuniq (talk) 23:18, 7 April 2019 (UTC)

RfC: Should the Administrators policy be amended to include a recommendation to use two-factor authentication?

RfC: Should the Administrators policy be amended to include a recommendation to use two-factor authentication, as recommended at H:2FA?

Current text:

Two-factor authentication is available to administrators to further secure accounts from unauthorized use.

Proposed text:

Two-factor authentication is available to further secure accounts and is recommended for administrators able to use it.

- MrX 🖋 21:52, 8 April 2019 (UTC)

---

• Procedural close as an RfC at a central page like this is overkill considering the (current) Bugger-All discussion on the relevant talk page. Why the urgency to escalate /shrugs/ ——SerialNumber54129 22:42, 8 April 2019 (UTC)

There is no discussion on the relevant talk page (WT:Administrators). Has it been recently archived?- MrX 🖋 22:58, 8 April 2019 (UTC)

It's today's back-and-forth reverts to WP:ADMIN itself. ~ Amory (u • t • c) 00:42, 9 April 2019 (UTC)

An edit war led straight to an RfC on the content and omitted talk page discussion and all other forms of dispute resolution...? ——SerialNumber54129

• Procedural close. This issue has been discussed to death already. --BrownHairedGirl (talk) • (contribs) 22:53, 8 April 2019 (UTC)

I was not aware of a discussion about adding this text recommending 2FA to the policy. Could you please provide a link?- MrX 🖋 22:58, 8 April 2019 (UTC)

• Meh - but in general, policies should be about what you must do, not what is "recommended". — xaosflux ^Talk 00:03, 9 April 2019 (UTC)
  • I disagree that there was an issue with changing the text, but basically this. If we're going to require it, we can have that talk, but talking about what we "recommend" is bikeshedding. ~ Amory (u • t • c) 00:46, 9 April 2019 (UTC)
  • Agree, no point. · · · Peter Southwood ^(talk): 07:32, 9 April 2019 (UTC)
• Yes, for consistency with Wikipedia:Password strength requirements (WP:PSR), a policy that states:

  A strong password and password security are just one part of securing your account. Users with advanced permissions, and indeed all users, should be taking steps above and beyond these requirements to insure the security of their accounts. Two-factor authentication is now available to administrators and will hopefully be rolled out to all users in the near future.

  — Newslinger talk 04:21, 9 April 2019 (UTC)

• Yes. How is this controversial to anyone? And not least for consistency with PSR, as above.  — Scott • talk 09:09, 9 April 2019 (UTC)
• Oppose - I don't really see how this helps. The difference from "available" and "recommended" is very fine. If this was asking for all administrators to be forced to use this, then this would be fine (I'd oppose for the restriction, but at least it would make sense). I'd also mention that having an option just for administrators that is suggested for security, which isn't currently available for all users grinds me up a little. Best Wishes, Lee Vilenski ^{(talk • contribs)} 09:22, 9 April 2019 (UTC)
• No per xaosflux. Policies are for requirements, recommendations should go elsewhere. Otherwise we'll have people arguing that admins violate the policy by not following the recommendation to enable 2FA. Ivanvector (^Talk/_Edits) 10:45, 9 April 2019 (UTC)
• No. The purpose of policy pages is to specify required actions ("standards that all users should normally follow" if you want the official definition), not to act as coatracks for the personal opinions of assorted busybodies as to what they think other people ought to be doing. Regarding consistency with WP:PSR, as far as I can see the "above and beyond" language was unilaterally added by a single editor without discussion (Wikipedia:Security review RfC was the RFC that created WP:PSR, and nowhere either in that or in WT:PSR was there any agreement to recommend 2FA), immediately after that same editor tried and failed to get consensus for it; if anything, we should be removing the showboating from WP:PSR, not allowing this paranoia to spread to further pages. ‑ Iridescent 13:54, 9 April 2019 (UTC)

  That's a misrepresentation of the linked proposal, when Beeblebrox proposed that the password requirement "be amended to require that these users maintain a password solely for their Wikimedia login". It did not involve 2FA. The edit you link to was concurrent but separate.  — Scott • talk 13:09, 10 April 2019 (UTC)

• Maybe I think we do need to address the problem, but I'm not sure (maybe it is, just not decided) that this language does it best. What I think we really need is "If you want to have advanced permissions, you need to secure your account in these ways. If you don't, AND your hacked account starts being used to damage Wikipedia, you have to go through RFA (or whatever) to get your permissions back. If you ARE following our recommendations, and it gets hacked, we'll let you back in when you get control again" We really need a policy that says "Look, we can't see your password or know your security process, but we DO need people with advanced permissions to take this stuff seriously, and if you aren't maybe you shouldn't have advanced permissions". Yes, everyone can be hacked, but we need to draw a distinction between people who got their back door kicked in vs. those that left the door wide open and left a sign out front saying "take whatever you like". Policy needs to be tightened up on this. --Jayron32 14:16, 9 April 2019 (UTC)
• Recommended, yes; required, no. To my understanding, this is policy already. Jonathunder (talk) 14:22, 9 April 2019 (UTC)
• Yes - The policy page does more that explain strict rules. It's also a guide for editors who wish to be promoted to admin, and for new admins learning to fulfill their role. It describes expectations, abilities, and best practices. Using 2FA would have prevented several admin accounts from being compromised over the years. The least we can do is raise awareness that using this additional security measure is recommended. Like Scott, I have no idea why this is even controversial. - MrX 🖋 14:25, 9 April 2019 (UTC)
• No, because a "recommendation" in a policy page is quite pointless. If we were to require it, it would be a different story. Vanamonde (Talk) 18:25, 9 April 2019 (UTC)
• No need, per Iridescent. Recommendations are useless clutter in a policy page. ansh666 18:38, 9 April 2019 (UTC)
• No, and no need. Perhaps the OP should actually spend some time looking at the various Mediawikiwiki and Wikitech pages related to 2FA before pushing this any further. The extension is written and maintained by volunteers, there is no committed support of the extension by the WMF, there is no department or unit tasked with assisting users who have problems with 2FA, and it is specifically designed with the assumption that the user has full control (i.e. ownership with full admin permissions - eliminating anyone editing from a work computer, a library, a member of the military, etc.) of their hardware. These are not small issues. Right now the permissions only require interface administrators - users with a high degree of technical knowledge, most of them in regular communication with WMF staff who can leverage those relationships should they encounter a problem. Add in 1600 admins, 3/4 of whom don't use IRC and half of whom have minimal technical expertise and/or have no idea whatsoever who to contact if they have problems. Until the WMF takes proper ownership of the 2FA issue and provides proper support with an extension that doesn't require the user to have admin permissions on the hardware being used, this should be a suggestion only. For that matter, there's a good chance that many users have a 2FA option built into their security software that they can apply without going through the WMF at all, and it will be better tested and better supported than the WMF version. Risker (talk) 01:54, 10 April 2019 (UTC)

  an extension that doesn't require the user to have admin permissions on the hardware being used The solution to this is to not use a desktop computer as a 2FA device. Having a smartphone capable of running a code generator app is trivial. You could literally buy a second-hand old phone for very little money just to use for that if you had to. The 2FA documentation shouldn't be suggesting using the same computer for editing and 2FA at all.  — Scott • talk 12:27, 10 April 2019 (UTC)

  You could literally buy a second-hand old phone for very little money Firstly that's not true in all parts of the world, secondly not all admins have the disposable income required to purchase and maintain a smartphone (which is significant in some situations, even for a second hand one), and thirdly we should absolutely not be requiring any editor to spend any money in order to participate in Wikipedia. Thryduulf (talk) 12:35, 10 April 2019 (UTC)

  Also some people have disabilities that mean that using a smartphone is very difficult if not impossible for them. Just because something is trivial for a technically-savvy, able-bodied person with disposable income in an affluent Western country does not mean the same is true of everyone. Thryduulf (talk) 12:40, 10 April 2019 (UTC)

  Read the proposal again. It isn't requiring (your italics) anyone to do anything. And "affluent Western country" - wow. You need to let those dated and patronizing assumptions go and start paying attention. By next year, estimates Ericsson, 70% of the global population will have smartphones; 90% will have high-speed data access. 80% of those smartphone owners will be in Asia Pacific, the Middle East, and Africa.
  Regarding disabilities, again: this proposal is to add a recommendation, not a requirement.  — Scott • talk 12:53, 10 April 2019 (UTC)

• No, per Risker and Iridescent. If 2FA is ever fully supported by the WMF and technical barriers to adoption are very significantly lower than they are today then we can reconsider. Thryduulf (talk) 10:52, 10 April 2019 (UTC)
• No, partly per Risker. 2FA as currently implemented is a flawed technology based on a lot of assumptions which do not apply in many cases. Admins should make their own evaluation of whether 2FA is suitable for their circumstances, and there should not be a blanket recommendation to adopt a technology which will inappropriate for many admins. --BrownHairedGirl (talk) • (contribs) 11:26, 10 April 2019 (UTC)

  What do you mean by "flawed techology"? Legoktm (talk) 06:13, 15 April 2019 (UTC)

• No. Risker has come up with a show stopper here. It is bad practice (althought commonplace among Windows users) to use an account on a computer with local admin permissions for anything other than maintenance of that computer. It seems that 2FA requires that, so we shouldn't be recommending it. Phil Bridger (talk) 11:52, 10 April 2019 (UTC)

  Phil Bridger - wrong, and that comment is (in my opinion) quite close to sensationalist rhetoric. It's not a show stopper - Risker said nothing about needing administrative permissions day-to-day. To be clear, the technical requirements to use 2FA as currently implemented are: a) a device you can edit from normally, b) a device you can run a code generator app on (which may be, but preferably isn't the same device as (a)), and c) somewhere safe to store the scratch codes. To be fully protected, the device the code generator app is on should be entirely under your control (the second factor is "something you have", versus "something you know" being the password), but even if it isn't entirely under your control (such as a work machine) it's better than just a password as it's still a device the attacker must get access to. The code generating device needs to be something you have access to every time you log in, which is why a smartphone is the ideal device here. The most administrative access to a computer I think you could possibly need would be to install a code-generating app, which falls squarely in the "computer maintenance" zone. stwalkerster (talk) 12:48, 10 April 2019 (UTC)

Please don't accuse me of "sensationalist rhetoric", or anything close to it, when I was simply basing my comment on a reasonable interpretation of what Risker wrote, and which had not been questioned at the time I made my comment. Phil Bridger (talk) 12:54, 10 April 2019 (UTC)

Apologies, I didn't mean to specifically accuse you of it, merely point out that you appeared to have found a minor point and blown it way out of proportion from what actually is the case. While I'm still not sure how you made that leap, I've struck that part of my comment and respect that you did make that leap. I do stand behind the remainder of my comment though. stwalkerster (talk) 21:06, 10 April 2019 (UTC)

• No, regrettably. Everyone should be using 2FA as a matter of good practice, but I do recognise that not everyone has a smartphone, or other sensible code generating device options. I also recognise we have a fairly problematic hole in recovery from 2FA which we need to somehow resolve. Technologically, our 2FA implementation isn't really flawed here as far as I can tell - it's entirely the social side of it we seem to have a problem with. For the record, in contradiction to Risker's comment, I occasionally edit from my work computer without admin access just fine (not using my main account because they do HTTPS MITMing, but that's a different problem) - I do have my own smartphone with the code generating app on though, and I believe Risker was referring to "administrative access to the device" to be "the ability to install an app on a device". Also as a matter of good practice, everyone should be using a strong, unique password, and everyone should be wary of malware/keyloggers/etc when logging in on devices they don't have full control of, whether they use 2FA or not. stwalkerster (talk) 12:48, 10 April 2019 (UTC)
  • So in other words, you have access to *two* devices, which is more than many of our editors have. Please be aware that even having access to two devices doesn't make it less of a challenge, because of the way that data plans work in different countries. A code generated to me from a US server will cost me the "out of country" rate on my data plan, and could easily add up to a supplementary $50 cost per month. (I learned this from experience with 2FA on another US-server website I used to use. Note the past tense.) Other people will have different plans. Risker (talk) 13:33, 10 April 2019 (UTC)
    • A code generated to me from a US server 2FA codes are generated by the app on your phone. It doesn't require data.  — Scott • talk 13:49, 10 April 2019 (UTC)
      • Tell that to my phone plan. Risker (talk) 13:56, 10 April 2019 (UTC) Ahh, I think you've misunderstood my point. I edit solely on computers, never on phones; however the code was generated to my phone to be ported to my desktop. I didn't add software to my phone - and we get back to the issue of security software not being managed or supported by the WMF. Risker (talk) 14:00, 10 April 2019 (UTC)
        • Two devices are not required, but it's probably better security practice to do so. As I said originally, there are code generator apps available for Windows/macos/Linux/etc. The key thing to multi-factor (read: two-factor) authentication is to make use of different authentication factors in some way - and the three factors are commonly known as "something you know" (eg password, security questions, etc); "something you have" (eg U2F tokens, proof that you have access to a specific device - normally by code generator apps), and "something you are" (biometrics). Biometrics cause a continent's weight of privacy concerns, so the only real option is for you to prove posession of a "thing" somehow. Normally this involves some stored secret combined with the current time to produce a short code only valid for a short time. The secret is generated by the WMF, and transferred to your phone normally by you scanning a QR code, or by manually typing in the secret to the app. As such, the only data transfer to/from your phone from the perspective of your data plan should be the download of the two-factor authentication software. To be clear, this is specifically the TOTP protocol which Wikimedia use - other two-factor implementations do indeed send push notifications or messages to your phone, and of course they do communicate, but the advantage of TOTP is there is no communication in that way. Obviously, with some incomes and budgets in whatever country, this may not be economically feasible for an individual, and I understand not enabling 2FA in those cases, but if you can do it, IMHO you should do it, and you must keep those scratch tokens safe! stwalkerster (talk) 21:06, 10 April 2019 (UTC)
• Yes, it is obviously neeeded. And it actually should be made an enumerated requirement, not just a recommendation, since failure to do so that results in account compromise results in turn in a desysop. It's already a requirement, just one we're not listing.  — SMcCandlish ☏ ¢ 😼  13:02, 10 April 2019 (UTC)
• Support, in fact it should be mandatory. If you're an administrator on a site serving millions of users you have a responsibility to take some security precautions. AdA&D ★ 14:24, 10 April 2019 (UTC)
  • @Anne drew Andrew and Drew: you have a responsibility to take reasonable security precautions. 2FA is not reasonable for all administrators for various reasons - read this thread for some examples - and even if it was reasonable the WMF do not have the capacity required to support it for all admins. Thryduulf (talk) 16:26, 10 April 2019 (UTC)
• Please note a potentially relevant arbitration committee motion: Special:PermanentLink/891851004#Return of permissions for compromised administrator accounts. –xeno^talk 15:11, 10 April 2019 (UTC)
• No: I object on two grounds. First, a recommendation is not a policy, nor can it be one, by definition. Second (and far more relevant to this discussion), Risker, stwalkerster, and BrownHairedGirl all make good points here, especially amidst calls for 2FA being mandatory. (As an addendum, I would support Jayron32's proposal, to a certain extent.) —Javert2113 (Siarad.|¤) 20:05, 10 April 2019 (UTC)
• No This again? SportingFlyer T·C 04:24, 15 April 2019 (UTC)
• No. See [ https://krebsonsecurity.com/2019/03/why-phone-numbers-stink-as-identity-proof/ ] also see Multi-factor authentication#Disadvantages. --Guy Macon (talk) 06:06, 15 April 2019 (UTC)

  MediaWiki's current 2FA implementation has nothing to do with phone numbers. Legoktm (talk) 06:13, 15 April 2019 (UTC)

Proposed amendment to the arbitration policy

The Arbitration Committee has resolved by motion that:

Pursuant to the arbitration policy's section on "Ratification and amendment", the Arbitration Committee resolves that the following change to the arbitration policy will be submitted for formal ratification by community referendum:

The final paragraph of the "Conduct of arbitrators" section of the arbitration policy is amended as follows:

Any arbitrator who repeatedly or grossly fails to meet the expectations outlined above may be suspended or removed by Committee resolution supported by two-thirds of all arbitrators excluding:

1. The arbitrator facing suspension or removal, and;
2. Any inactive arbitrator who does not respond within 30 days to attempts to solicit their feedback on the resolution through all known mediums of communication.

This amendment to the arbitration policy will enter into force once it receives majority support, with at least one hundred editors voting in favour of adopting it. Until this amendment is ratified, the existing arbitration policy remains in effect.

The ratification process has begun at Wikipedia:Arbitration/Policy/Proposed amendment (April 2019). Your participation is welcomed. ~ Rob₁₃^Talk 02:22, 9 April 2019 (UTC)

RfC: Nature of bureaucrats' discretionary range for closing RfAs

There's an RfC at Wikipedia talk:Requests for adminship#RfC on the nature of bureaucrats' discretionary range for closing Requests for Adminship on the extent to which the discretionary range is a unified block and the extent to which it's a spectrum. All editors are invited to participate. Sideways713 (talk) 10:21, 12 April 2019 (UTC)

Organization of Impacts

Moved from Talk: April 2019 North American Blizzard

After reading through the WP:MOS trying to find an answer, I officially could not come up with a conclusion or right answer, which is why I would like some help. I have even been through the Missing Manual as well as the Beginner's guide. So, would chronological order be right for impacts (this is the current form in the article) or is alphabetical order (used in March 2019 North American blizzard) correct? I thank you for your time and answering. Zanygenius_{(talk to me!)(email me!)} 03:00, 12 April 2019 (UTC)

Zanygenius, I'm unsure whether you are seeking advice or you're concerned about being "correct" according to rules. My guess is that the MOS doesn't provide an answer on something that specific. This might not be the answer you're looking for, but we're more concerned with "improvement" than "correct". You can do whatever you think best so long as the encyclopedia is better with your edit than without it. If/when someone wants to change it, they can provide a rationale or MOS-link for why they think their change would be an improvement. Alsee (talk) 15:37, 12 April 2019 (UTC)

Alsee, Thank you for your feedback. In a way, I was seeking advice on whether alphabetical style or chronologial style was best ofr the subject area I was working in. So you're saying that there isn't a certain order that it must follow, and that if another user has objections they may point out a paragraph at WP:MOS? Zanygenius_{(talk to me!)(email me!)} 16:10, 12 April 2019 (UTC)

Zanygenius, Correct. Although to be more precise, I doubt the existence of any formal position on something that specific. No one can know every MOS and guideline and consensus. We're merely expected to respect them when somebody (validly) cites them as a justification for their edit.
As for advice, my impression is that chronological does sound useful but I haven't really looked into it. If there were an editing dispute I'd dig into it and try to help sort it out, I do a lot of that kind of work answering RFCs via the Feedback Request Service. Without a dispute you can be bold in using your judgement on how to improve Wikipedia. Oh... I just thought of WikiProject Meteorology, or maybe WikiProject Non-tropical storms. Those Talk pages don't seem to have much recent dialog, but you may find useful information or people with topic expertise there. Alsee (talk) 19:23, 12 April 2019 (UTC)

Hi Alsee, yes Chronological order can be useful in timelines an sometimes events, and thank you, I'll go ahead and check out those projects. Essentially, the best thing to do is choose as see fit, and if no-one expresses concern, then it's fine? Okay then. Thank you very much. Zanygenius_{(talk to me!)(email me!)} 03:18, 13 April 2019 (UTC)

Editing

I have given modest amounts of cash to Wikipedia. But I find the editing can be a bit off-hand. I think if a considered contribution is taken off, there should be some reason given.

I doubt if I'll give $$ in the future.

Yours cordially

M Cochran — Preceding unsigned comment added by 2001:8003:A101:A100:A550:D085:7AAC:7B7B (talk) 23:34, 12 April 2019 (UTC)

• Cochran, if you've found editing a bit off-hand, because some addition that you did to an article was reverted, you are absolutely right that an explanation should be given. If you can point us to the actual edit that you undertook and was reverted, we could give more information on the same.

To your other point, donating money to Wikipedia is a voluntary act (and we're thankful for the same), as voluntary an act as editors like I do in donating our time to Wikipedia. Our project is probably still committed to not allowing the inter-mingling of these two facets, where financial donations can influence editorial decisions. Therefore, whether you donate to us or not, your editorial contributions will be viewed independent of that, for their own worth. If there's anything else you need assistance in, do ask. Thanks, Lourdes 03:47, 13 April 2019 (UTC)

Long pages

Our longest 50 pages are all over 425,000 bytes of wiki markup. On several of their talk pages, there are some editors resisting splitting them, often arguing that WP:TOOLONG does not apply because the pages are made up of tables, not "readable prose".

I do not believe it was the community's intention, when WP:TOOLONG was drafted, to allow pages of such size. Do we need a project wide RfC, or is there a better way of setting this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 13 April 2019 (UTC)

Could you link to a few examples so we can see some context? Blueboar (talk) 14:48, 13 April 2019 (UTC)

• Talk:Opinion polling for the 2019 Spanish local elections#Split
• Talk:Mobile country code#Too long
• Talk:Opinion polling for the 2018 Italian general election#Split
• Talk:Constituency election results in the 1929 United Kingdom general election#Page length (no response to initial post)
• Talk:Timeline of 1960s counterculture#Article too long
• Talk:2017 in American television/Archive 1#Page length - note this was recently archived
• Talk:2018 in American television/Archive 2#Split proposal - also archived recently
• Talk:List of compositions by Franz Schubert#This article is far too long
• Talk:List of compositions by Johann Sebastian Bach#Splitting article

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:45, 13 April 2019 (UTC)