Jump to content

Wikipedia talk:What Wikipedia is not: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Minor alteration to WP:NOTDIRECTORY: Proposed variation to NOTDIRECTORY and Request for Comments
Line 61: Line 61:
:I have a proposal I think will be helpful to readers that I will post to this thread in a few minutes when I get some time. [[User:Huggums537|Huggums537]] ([[User talk:Huggums537|talk]]) 00:28, 30 May 2023 (UTC)
:I have a proposal I think will be helpful to readers that I will post to this thread in a few minutes when I get some time. [[User:Huggums537|Huggums537]] ([[User talk:Huggums537|talk]]) 00:28, 30 May 2023 (UTC)
*While I agree with the idea of the proposal in spirit, I think it would still have the problem of my original complaint about having two different sets of guidance in two different places, so I am going to suggest a slight variation to the proposal in a new subsection to this thread that I think will resolve the problem, and be more useful to both readers and editors alike because it will be less confusing, and less contradictory to each other. Plus, I wholeheartedly agree with the OP that the dispute should be settled at the appropropriate DAB guidance pages, and my new proposal listed in the next subsection will direct editors there. Thanks. [[User:Huggums537|Huggums537]] ([[User talk:Huggums537|talk]]) 01:01, 30 May 2023 (UTC)
*While I agree with the idea of the proposal in spirit, I think it would still have the problem of my original complaint about having two different sets of guidance in two different places, so I am going to suggest a slight variation to the proposal in a new subsection to this thread that I think will resolve the problem, and be more useful to both readers and editors alike because it will be less confusing, and less contradictory to each other. Plus, I wholeheartedly agree with the OP that the dispute should be settled at the appropropriate DAB guidance pages, and my new proposal listed in the next subsection will direct editors there. Thanks. [[User:Huggums537|Huggums537]] ([[User talk:Huggums537|talk]]) 01:01, 30 May 2023 (UTC)
*Also, it has been nearly a month without any more participation on this, and we need to resolve it after months of debate, so I think it is time to invite the broader community on a request for comment with this proposal since the last RfC from the broader community about this was opened to avoid a "local consensus", and so an RfC is due again since we actually can't find any consensus this time for real. [[User:Huggums537|Huggums537]] ([[User talk:Huggums537|talk]]) 03:16, 30 May 2023 (UTC)

==Proposed variation to WP:NOTDIRECTORY (revisiting simple lists)==
{{rfc|policy}}
This RfC determines if the following changes be made to NOTDIRECTORY based on the discussion in the above thread:
{{blockquote|[Wikipedia articles are not:] '''Simple listings''' without [[Wikipedia:Writing better articles#Provide context for the reader|contextual information]] showing encyclopedic merit. [[WP:DAB|Disambiguation pages]] (such as [[John Smith (disambiguation)|John Smith]]) are not intended to be complete listings of every person named John Smith—just the ones '''''as defined at [[MOS:DABMENTION]], or within the scope of [[Wikipedia:Disambiguation|disambiguation]] or [[Wikipedia:Manual of Style/Disambiguation pages|style]] guidance.'''''}} ''Changes highlighted in bold and italica.''

The link to DABMENTION sums up what is being said in the above proposal, and leads the reader/editor to the appropriate ''specific'' guidance, where the details of what should happen with those pages (such as what "well discussed" means) can be hashed out there (where the debate has no effect on this decision here), but it also lets readers/editors know that there is some kind of ''specific rules'' that ''prevent you'' from making a "complete listing" on DABs without incorrectly saying it is based on the more "''generalized''" notability guidance. I'd also like to point out that the closing of the previous RfC indicated that there was a common thread on both sides of the debate that the wording could be better tuned to cover ''commonly accepted additions to DABs'', and I think this ''absolutely is'' that change. A solution ''far'' better than IAR, (because IAR could be argued for any side of the debate).

I can't ping everyone that was involved in the previous RfC because I think it limits the pings so just pinging to users who participated in the original discussion. Those who were involved in the previous RfC will probably see it again.
{{ping|Tavix|BilledMammal|Masem|Blue Square Thing|Certes|PamD|Uanfala|Jsharpminor|Avilich|Firefangledfeathers}}

*'''Support''' as nominator because it just plain makes sense. [[User:Huggums537|Huggums537]] ([[User talk:Huggums537|talk]]) 03:16, 30 May 2023 (UTC)


== RFC on putting data in context ==
== RFC on putting data in context ==

Revision as of 03:16, 30 May 2023

Minor alteration to WP:NOTDIRECTORY

There has been an odd feud going on in the past year, around a conflict between this policy and disambiguation practice. Background information can be read through these starting points: Wikipedia talk:What Wikipedia is not/Archive 58#Recent correction to Simple Lists, this torturous RfC, and Wikipedia:Articles for deletion/Charles Lott. It has been suggested that another discussion be opened, and the issue has not been resolved in the slightest – so here we are.

@BilledMammal and BD2412: It is clear that inclusion guidelines for disambiguation pages should be set out at WP:DAB or MOS:DAB, as they are, and not in a remote section of a largely unrelated policy. As it stands, the passage was added on a whim in 2014 and it took years for the discrepancy to be noticed. Therefore, I propose that the conflicting paragraph here be reworded to eliminate the current state of disorganisation, from

[Wikipedia articles are not:] Simple listings without contextual information showing encyclopedic merit. Disambiguation pages (such as John Smith) are not intended to be complete listings of every person named John Smith—just the notable ones.

to

[Wikipedia articles are not:] Simple listings without contextual information showing encyclopedic merit. Disambiguation pages (such as John Smith) are not intended to be complete listings of every person named John Smith—just the ones well-discussed on Wikipedia.

or some alternative verbiage which serves the purpose, and that this dispute be taken to WT:MOSDAB or WT:DAB instead. J947edits 08:38, 27 April 2023 (UTC)[reply]

Is this dispute still happening? I'm sure I've commented on this somewhere else a few months ago, and I thought consensus had been reached that disambiguation pages should not be restricted to only those people with individual articles but anyone who had enough coverage somewhere to meet WP:DABMENTION. This seems to be the intent of J947's suggestion, which I therefore endorse. Thryduulf (talk) 10:16, 27 April 2023 (UTC)[reply]
Attempting to correct behavioral issues with minor wording changes is an interesting tactic, though unlikely to result in the changes you seem to imagine it will. --Jayron32 13:19, 27 April 2023 (UTC)[reply]
I wholeheartedly support that change as that would bring that sentence in line with current practice, while still maintaining that disambiguation pages should not be used to list people that are not noteworthy. -- Tavix (talk) 14:15, 27 April 2023 (UTC)[reply]
I agree that "well-discussed" should be the minimum requirement here (iff "notable" is removed or is not enforced). I do not think it makes any sense to have different thresholds for "discussed-ness" that depend on size of DAB page -- a passing mention in an article should not get its own blurb on a DAB page just because there are only two other names there. JoelleJay (talk) 18:01, 27 April 2023 (UTC)[reply]
Oppose - I don’t understand why we should be DABing eg non-notable players on football teams, non-notable actors on TV serieses etc. Notability is not about whether people DO have a page, it’s about whether they COULD have a page. This proposal just seems to serve to greatly inflate the number of names mentioned on DAB pages without making them more useful - “well discussed” is not a clear definition whilst “notable” is something Wiki edits deal with a lot. FOARP (talk) 20:26, 5 May 2023 (UTC)[reply]
It is The Reader that we should consider on each and every edit we make to Wikipedia.

(Thanks to Alan Liefting, via BMK)

  • Having been pinged to this discussion, I will note that in all of these discussions, I have seen virtually no mention of what is actually most helpful to the reader. I will readily grant that for a lengthy disambiguation page (like John Smith or Robert Jones), it would be excessive to cram in a lot of mere mentions, but for a relatively short page (like the above-mentioned Charles Lott), it may well be useful to the reader to list some of those subjects currently omitted from the page. BD2412 T 14:35, 27 April 2023 (UTC)[reply]
    For pages that would not exist if they didn't include mere mentions the user is better served by having no page, as such pages are rarely maintained and thus rarely produce up to date results, unlike the search function. We shouldn't change policy to support the creation of these pages.
    For pages that would otherwise exist due to multiple notable people having the name, I can see the use of including them, but I would argue we would be better served by adding a button that allows users to search for the name, preferably excluding from the results the articles in the dab page. The reason for this is I doubt the passing mentions will be better updated in a dab-page that includes notable people than one that doesn't include notable people, and thus readers are more likely to find the person they are looking for if they are directed to up to date search results - and are unlikely to think of searching themselves if they just see the list, as they are likely to assume it is complete.
    For pages where exactly one notable person has that name, I am not certain of the best approach. BilledMammal (talk) 20:41, 27 April 2023 (UTC)[reply]
Part of the problem may be that John Smith is not a typical name dab. The huge number of people bearing one of the most common names in the English-speaking world makes WP:NOTABLE a reasonable threshold for that page. However, the bar should be set much lower for a more typical name dab which lists only a few or even a few dozen people. There, it is far more likely that a reader will be seeking someone with a mere WP:DABMENTION and no article, so we should include them. Certes (talk) 18:13, 27 April 2023 (UTC)[reply]
How on earth is it more likely that someone would be seeking a DABMENTION for a less common name than for a "John Smith" name? More people will be searching for non-notable John Smiths than non-notable [rare names] simply because more people exist with that name. If anything, the more common the name the more useful a DAB is for non-notable items! And how would we decide to include a namedrop without knowing how many people will ever be at a DAB page, considering the near-impossibility of removing DAB entries (I have been told that, barring deletion of the info in an article, there is never a good reason to remove a name)? No, the bar for inclusion should be equal for all DABMENTIONS. JoelleJay (talk) 00:21, 28 April 2023 (UTC)[reply]
  • "Well-discussed" should be clarified to mean that entries in set-index articles are allowed, and entries like (using the example above) the non-notable character Charles "Chuck" Lott in Between (TV series) are not. Otherwise, no change. Readers will only hear about Charles "Chuck" Lott if they know about the TV series; if they do, searching will be redundant, and if they don't, they won't want to search for him in the first place. Avilich (talk) 00:38, 28 April 2023 (UTC)[reply]
    While that may seem intuitively obvious, I'm not sure it's as absolute as you just stated. While rare, someone may come to Wikipedia trying to remember which TV show that Chuck Lott character showed up in. Of course, Google will likely be more useful than us, but people might just occasionally ask that question. Jclemens (talk) 02:05, 28 April 2023 (UTC)[reply]
    I'm not hot on popular culture, especially American popular culture, so I often have to look up names etc to learn who is being referred to - I don't always even know if it is a person (e.g. actor) or a character. Dabmentions are often helpful for this as they either give sufficient context themselves or give enough information that I know where to look for further context. Thryduulf (talk) 08:34, 28 April 2023 (UTC)[reply]
That may be true, but Google itself probably takes care of that on its own. Avilich (talk) 00:36, 29 April 2023 (UTC)[reply]
Assuming everyone uses Google. I tend to search Wikipedia first. WhatamIdoing (talk) 03:10, 29 April 2023 (UTC)[reply]
Often the top google hits don't provide the necessary context for someone who doesn't already know the basics. Long-running TV shows are probably the most common example, with the top results being fan pages and articles in magazines and similar written by and for people who have been following from (near) the beginning. Wikipedia can be relied upon to have an introduction that either requires no prior specialist knowledge or clear links to where that knowledge can be gained (at least in all the subject areas relevant to this discussion) so it is typically a more useful starting point. Thryduulf (talk) 08:53, 29 April 2023 (UTC)[reply]
I have a proposal I think will be helpful to readers that I will post to this thread in a few minutes when I get some time. Huggums537 (talk) 00:28, 30 May 2023 (UTC)[reply]
  • While I agree with the idea of the proposal in spirit, I think it would still have the problem of my original complaint about having two different sets of guidance in two different places, so I am going to suggest a slight variation to the proposal in a new subsection to this thread that I think will resolve the problem, and be more useful to both readers and editors alike because it will be less confusing, and less contradictory to each other. Plus, I wholeheartedly agree with the OP that the dispute should be settled at the appropropriate DAB guidance pages, and my new proposal listed in the next subsection will direct editors there. Thanks. Huggums537 (talk) 01:01, 30 May 2023 (UTC)[reply]
  • Also, it has been nearly a month without any more participation on this, and we need to resolve it after months of debate, so I think it is time to invite the broader community on a request for comment with this proposal since the last RfC from the broader community about this was opened to avoid a "local consensus", and so an RfC is due again since we actually can't find any consensus this time for real. Huggums537 (talk) 03:16, 30 May 2023 (UTC)[reply]

Proposed variation to WP:NOTDIRECTORY (revisiting simple lists)

This RfC determines if the following changes be made to NOTDIRECTORY based on the discussion in the above thread:

[Wikipedia articles are not:] Simple listings without contextual information showing encyclopedic merit. Disambiguation pages (such as John Smith) are not intended to be complete listings of every person named John Smith—just the ones as defined at MOS:DABMENTION, or within the scope of disambiguation or style guidance.

Changes highlighted in bold and italica.

The link to DABMENTION sums up what is being said in the above proposal, and leads the reader/editor to the appropriate specific guidance, where the details of what should happen with those pages (such as what "well discussed" means) can be hashed out there (where the debate has no effect on this decision here), but it also lets readers/editors know that there is some kind of specific rules that prevent you from making a "complete listing" on DABs without incorrectly saying it is based on the more "generalized" notability guidance. I'd also like to point out that the closing of the previous RfC indicated that there was a common thread on both sides of the debate that the wording could be better tuned to cover commonly accepted additions to DABs, and I think this absolutely is that change. A solution far better than IAR, (because IAR could be argued for any side of the debate).

I can't ping everyone that was involved in the previous RfC because I think it limits the pings so just pinging to users who participated in the original discussion. Those who were involved in the previous RfC will probably see it again. @Tavix, BilledMammal, Masem, Blue Square Thing, Certes, PamD, Uanfala, Jsharpminor, Avilich, and Firefangledfeathers:

RFC on putting data in context

This policy says To provide encyclopedic value, data should be put in context with explanations referenced to independent sources.

I believe that some editors, especially less experienced editors, would benefit from some idea of what it means to put information in context. I therefore propose adding a link to Wikipedia:Writing better articles#Provide context for the reader (e.g., so that it reads To provide encyclopedic value, data should be put in context with explanations referenced to independent sources). What do you think? WhatamIdoing (talk) 22:22, 28 April 2023 (UTC)[reply]

  • Support. Don't see any reason there shouldn't be a link there. I feel this could've been done boldly. CLYDE TALK TO ME/STUFF DONE 23:40, 28 April 2023 (UTC)[reply]
    It was, then it was reverted, discussed, and now formally proposed for more input. isaacl (talk) 03:50, 29 April 2023 (UTC)[reply]
  • Support A logical and useful change. Cullen328 (talk) 03:07, 29 April 2023 (UTC)[reply]
  • Oppose, per discussion above. The goal of this policy is to avoid editors dumping data in articles without providing prose explaining the data or making it clear to the reader why it is relevant. This is different from the goal of the essay that the nominator proposes linking, which is to ensure that the reader can understand the content. Making this change will make this policy less clear, as some editors will argue that it is sufficient to ensure that the data can be understood. Further, I don't see any benefit of adding this; do we really need a policy telling editors to ensure that content they add can be understood by readers? BilledMammal (talk) 03:09, 29 April 2023 (UTC)[reply]
  • Support data spamming with zero context is a problem....need more explained from the link at Template:Too many charts.Moxy- 03:56, 29 April 2023 (UTC)[reply]
    @Moxy: I don't see how the link provided will address the problem; my concern is that it will make data spamming without context a larger problem, by making editors believe they have provided context when all they have done is made the data comprehensible. BilledMammal (talk) 04:03, 29 April 2023 (UTC)[reply]
    What text do you propose then? Dont see how a link will have a negative effect. Moxy- 04:29, 29 April 2023 (UTC)[reply]
    I'm not convinced any text is needed; I can't imagine any situation where a policy telling editors to make data comprehensible will be helpful, because I can't imagine any situation where an editor is arguing that data shouldn't be comprehensible.
    However, if we are going to add text, it should be some form that explains that the data needs to be discussed, directly or indirectly, in the prose, and that the discussion in the prose needs to be referenced to independent sources. BilledMammal (talk) 16:43, 29 April 2023 (UTC)[reply]
  • I don't share the concern regarding the proposed change making the inclusion of irrelevant data a bigger problem, as I think this should be covered within point 3, "Excessive listing of unexplained statistics". Perhaps a link to Wikipedia:Writing better articles § Stay on topic could be added to this point, such as Any data or statistics included in an article should have directly relevant to the topic under discussion (see Wikipedia:Writing better articles § Stay on topic). isaacl (talk) 04:33, 29 April 2023 (UTC)[reply]
    I'm not sure if that will resolve the problem; my concern is that editors will use this change to support the creation of articles that are database entries in prose form. WhatamIdoing, do you see this change being used as an argument against editors who argue that this policy prohibits such articles? BilledMammal (talk) 16:43, 29 April 2023 (UTC)[reply]
    I personally don't see the proposed change playing a role with that concern. I believe the consensus view is that evaluating whether a topic meets Ehglish Wikipedia's standards for having an article is separate from making editorial decisions on the relevancy of article content. From past discussion, I believe WhatamIdoing does feel that a good-sized article with relevant info should meet English Wikipedia's standards. But as far as I can tell, this isn't the prevailing view. I don't think there is general agreement that just because we can document certain relevant characteristics about a topic, that we must cover it in a standalone article. isaacl (talk) 17:11, 29 April 2023 (UTC)[reply]
    I agree that whether we have an article at all (notability) is a completely separate consideration from the editorial decisions about what goes in the article (e.g., putting data in context instead of just spamming it onto a page). WhatamIdoing (talk) 04:08, 30 April 2023 (UTC)[reply]
    @BilledMammal, to answer your question, I'd have to understand what you mean by "database entries in prose form". Take a look at User:WhatamIdoing/Database article. It is Is that the kind of article you want to discourage? WhatamIdoing (talk) 04:04, 30 April 2023 (UTC)[reply]
    I'm asking if this change will be used to argue against this sort of article, or any sort of article, being a violation of NOTDATABASE. What I am asking is whether this change will have any impact on how this policy is currently used, and the fact the answer isn't an immediate "no" concerns me. BilledMammal (talk) 01:14, 2 May 2023 (UTC)[reply]
    Two unrelated thoughts:
    • Would that two-sentence article bother you if the contents were the same, but it had been cited instead to a book called Dansk Fodbold i Efterkrigstidens Vidunderår ("Danish Football in the Post-War Wonder Years") and to a magazine article titled "How a 1953 Injury in a Footballer's First and Only Professional Game Changed the Players' Union Forever", instead of to the two websites that were actually used?
    • I don't think this change would make any difference in the ongoing arguments about whether tiny articles cited to databases are desirable. Fundamentally, "data should be put in context" assumes that there is a page for the data to be put in context on, because you can't put data in context if no page exists to put either the data or the context on. But more realistically, if less logically, if someone believes that Wikipedia:What Wikipedia is not#Wikipedia is not an indiscriminate collection of information means that it's fine to have encyclopedia articles cited to databases so long as it's an encyclopedia article (e.g., written in prose, with a formal tone) and not a database entry, or, conversely, if someone believes that it Wikipedia:What Wikipedia is not#Wikipedia is not an indiscriminate collection of information means that policy bans the creation of pages cited only to databases, then I can't imagine that a link to Wikipedia:Writing better articles, which says nothing about the potential validity of databases as sources, will change their minds.
    WhatamIdoing (talk) 02:04, 2 May 2023 (UTC)[reply]
  • Oppose A nice section in a good essay which is one of the thousands of good essays. But that isn't what this policy is about plus there would need to better more of a rationale for being one of the tiny fraction of essays that are linked in core policies. North8000 (talk) 17:35, 29 April 2023 (UTC)[reply]
    Wikipedia:Writing better articles is already linked in two other sections of this policy, so if you feel that we needed a special rationale for linking this MOS {{supplement}}, that discussion probably should have been held at least five years ago. WhatamIdoing (talk) 03:40, 30 April 2023 (UTC)[reply]
  • Oppose. Both the advice to contextualize data by adding prose explanations and the advice to think of the reader and make prose content accessible by providing enough context within the prose in the link target are good advice, but they are advice about different things. —David Eppstein (talk) 04:41, 30 April 2023 (UTC)[reply]
  • Weak oppose. on balance, (Summoned by bot) Both the advice to contextualize data by adding prose explanations and the advice to think of the reader and make prose content accessible by providing enough context within the prose in the link target are good advice, but they are advice about different things. Also I have a cynical tendency to think that P&G are already too many and too verbose and new editors avoid implementing for other reasons generally Thus extending them should be resisted except where there is a demonstrable problem with existing policies. Pincrete (talk) 05:57, 4 May 2023 (UTC)[reply]
  • Support, the link provides helpful context, which seems particularly on-point for this particular policy. -- Visviva (talk) 20:26, 6 May 2023 (UTC)[reply]
  • Support I understand User:Pincrete's hesitation to support and might agree not to add presumably unnecessary information in other situations. I think this particular link would provide a useful clarification and good guidance because I have seen misunderstandings about the need for citing reliable sources and notability policy ignored by new users perhaps often due to lack of knowledge of how to support an article as well as what is required for an article to be published. The link may or may not be followed. I think that anyone interested in making useful contributions will not be put off by a link, perhaps may not click on it and, if not already understanding the text, might find the further information helpful if they do click on it. It could reduce the need for further explanations or warnings to new users. Donner60 (talk) 10:04, 14 May 2023 (UTC)[reply]
  • Oppose WP:PCR doesn't give any guidance as to how to ensure data is contextualized. This requires a new essay on how to write effectively about data. voorts (talk/contributions) 23:26, 21 May 2023 (UTC)[reply]
Oppose: such a change implicitly incorporates an essay into a guideline, which is inappropriate when that essay has not been endorsed by consensus Jack4576 (talk) 14:48, 22 May 2023 (UTC)[reply]
@Jack4576, when your block expires, please note that:
  1. This policy (not guideline) already links to the same section of the same essay in Wikipedia:What Wikipedia is not#Wikipedia is not a directory.
  2. The policy about policies says Policies and guidelines may contain links to any type of page, including essays and articles.
WhatamIdoing (talk) 22:34, 22 May 2023 (UTC)[reply]

RFC on removing WP:NOTCHANGELOG policy

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There's broad consensus to retain WP:NOTCHANGELOG, though some interest in rephrasing it. No particular rephrasing was much-discussed or gained consensus so that'll have to be the focus of a future proposal. Ajpolino (talk) 17:32, 28 May 2023 (UTC)[reply]

Should WP:NOTCHANGELOG be removed? 00:38, 2 May 2023 (UTC)

  • I am starting an RFC to debate the removal of the WP:NOTCHANGELOG policy, specifically the policy relating to software updates. This policy is threatening the removal of several articles on Wikipedia that are crucial to the history of software, such as Firefox version history and iOS version history. One article was already impacted, the version history page for Google Chrome, and Firefox version history's removal is additionally being debated and might be gone by the time this RFC gains traction. These articles have existed on Wikpedia for a long time, with one article, the Firefox version history article, having existed on the platform since 2012, and Google Chrome's version history article having existed since 2013. The removal of information from a critical platform like Wikipedia is downright unacceptable, and policies that actively hurt the ability for articles like these to exist are additionally unacceptable, especially when these articles are severely notable and have been cited and referred to by many, many people and publications. There is no other platform that has of comprehensive of version history articles of software that Wikipedia does, and this information is severely useful to know how software, like Firefox, has advanced. This policy is detrimental to the health and prosperity of Wikipedia as a platform, and as my personal opinion, this policy needs to be removed.
Additionally, the iOS version history article has existed since literally 2008. So even older than both Firefox's and Google Chrome's version history pages. There is precedent for these articles to exist, which is an additional reason for this policy to be removed from the platform. Why have the policy go into effect 15 years after these articles were created? This makes no sense. This is unacceptable, especially when these articles have, like I mentioned, existed for over a decade each, and some for almost two. This is downride sad, and detrimental to Wikipedia as a platform where information like that apparently can't exist. - Evelyn Marie (leave a message · contributions) 00:38, 2 May 2023 (UTC)[reply]
  • Those pages on the Firefox and iOS version history violate the purpose of an encyclopedia, which is to summarize what reliable secondary sources discuss, not what primary sources repeat, so no, we absolutely should not remove it. Masem (t) 01:13, 2 May 2023 (UTC)[reply]
Wikipedia is not a typical encyclopedia, it is a wiki. It is a collection of information that reflects the history, past, and present of subjects. iOS and its versions, for example are a part of history that deserve to be covered. Same with the Firefox version history page. Wikis are vast collections of information. Wikipedia has not been an "encyclopedia" in the classic sense since it was conceived, and removing information from Wikipedia shouldn't be encouraged, especially if it has merit / value to existing and is adequately sourced. Plus, these policies aren't even actual policies or rules - they are guidelines. And this is a guideline that honestly needs to be removed. It has not reflected the current use for Wikipedia as a platform in literally 15 years. It is a policy that people are wanting to somehow enforce. "List"-class articles aren't encyclopedic either and yet they have lots of value and merit to existing, just as these version history pages do.
I've said this before and I'll say it again - Information deserves to be preserved, recorded, and kept. Not erased or deleted. - Evelyn Marie (leave a message · contributions) 03:17, 2 May 2023 (UTC)[reply]
Also, in my opinion @Masem you are relying on an ancient purpose / use for Wikipedia as an information platform. You have been an active opponent of changelogs since 2011, as seen by the discussions regarding changelogs that have previously been discussed in these policies (back when Wikipedia was more actively contributed to) of which you have participated, and in my opinion you are not speaking from a neutral point of view, nor of the view of most Wikipedia readers. This is not 2011-2013 anymore - and as clearly shown by the fact that the iOS version history article for example kept its tables for as long as it did, until they were removed for copyvios and then restored based on consensus as an editor went through the massive trouble of rewriting the table content to lose the copyright violations (@DFlhb thank you), it is clear that these tables are valuable to a lot of people. Additionally, the only reason the tables were removed recently was because of the fear of the article being removed on the basis of this guideline due to the arbritrary and sudden enforcement of this policy despite it not being enforced for over 15 years. It is very clear that most people who visit Wikipedia, specifically version history articles, consider these types of pages to be valuable. I am fully aware of the WP:ITSUSEFUL policy, however these version history articles are severely, and I mean severely valuable to software history, so much so that people additionally cite these types of articles in their YouTube videos. And they were adequately sourced as well.
Wikipedia's purpose has evolved since 2011, not to mention 2011 was 12 years ago. This policy is shameful, not to mention very, very divisive. It is also a policy that contributes to the active removal of valuable information from Wikipedia when no policy should exist that allows the removal of sourced, valuable, and important information from Wikipedia. - Evelyn Marie (leave a message · contributions) 04:01, 2 May 2023 (UTC)[reply]
Not really "restored based on consensus"; more like based on agreeableness on my part, though I wasn't strongly opposed to the tables.
But Masem, I'd appreciate your thoughts on this whole comment as it applies not to Firefox (I'll concede that one), but to version history articles in general. In the recent AfDs, I think people are overreacting, and swinging from completely ignoring NOTCHANGELOG to interpreting it far too strongly. IMHO, NOTCHANGELOG is about dueness and level of detail, not about a requirement that everything must have an inline secondary source (i.e. GA-class!). Yet in recent AfDs, I've seen the latter sentiment expressed a lot. We still have a lot of version history articles, and most of them don't go into outrageously excessive detail; they just lack inline citations, just like all our articles do, and I'd hate to see them all AfD'd since the mere lack of inline citations, and the need for a trim of undue detail, are WP:SURMOUNTABLE. I'm proposing we clarify NOTCHANGELOG to state that it's about level of detail, not inline citations actually being present. Thoughts? DFlhb (talk) 04:53, 2 May 2023 (UTC)[reply]
If pages violate established policy but do not get subjected to large-scale review of the policy they violate (which happens a lot when there are 4+ million pages on WP), that doesn't mean policy has shifted to a new form supporting that article; it only means that the article was constructed willfully ignoring policy. WP's purpose is to summarize content as seen through the eyes of reliable sources, not wholly repeat it. If the material is so important, then it should be on third-party wiki sites (like I can't believe the iOS history is not on some Apple fan site somewhere, for example, if not on Apple.com somewhere itself). Masem (t) 12:15, 2 May 2023 (UTC)[reply]
The information isn't "destroyed", it's just somewhere else where it fits, like Wikidata. Aaron Liu (talk) 12:33, 2 May 2023 (UTC)[reply]
  • I've adjusted this RfC to comply with WP:RFCNEUTRAL, by changing the initial statement to a simple statement and moving this statement, which originally was the initial statement, to a response. BilledMammal (talk) 01:16, 2 May 2023 (UTC)[reply]
  • IOS version history should be fine as an article, since it has actual prose sourced from secondary sources as described at WP:NOTCHANGELOG, and it only lists the major releases for which there is actually a lot of third-party sources and reviews for each (rather than point releases like iOS 16.1 etc). WP:NOTCHANGELOG does not prohibit version history, but merely requires the information to be sourced from third-party sources, i.e. a version history article, like any other "history of" article, should be sourced from third-party sources. Galobtter (talk) 01:24, 2 May 2023 (UTC)[reply]
  • Oppose removal. The problem of huge unencyclopedic CHANGELOG articles that list all updates to all versions of pieces of software is that they go into far too much unnecessary detail, rather than telling an understandable and properly sourced encyclopedic story about the history of the software. That problem cannot be fixed by silencing any part of our guidelines that points out that it is a problem. —David Eppstein (talk) 01:29, 2 May 2023 (UTC)[reply]
  • Oppose removal. Changelogs are point by point version history stuff almost 100% in list form. Note that this point says exhaustive logs, not all changelogs. This criteria does not apply to the article as they don't just list a ton of stuff and instead coalesce the major changes, reliably sourced with nontrivial impact. We could expand this criteria to elaborate on this, but we shouldn't just remove this criteria. Aaron Liu (talk) 01:36, 2 May 2023 (UTC)[reply]
  • Oppose. Changelogs are usually overdetailed, have repetitive text, and aren't formatted in an encyclopedic tone. iOS version history, by comparison, is not a changelog. It treats each OS version as a thing in its own right, and only has one paragraph per version for a condensed and good overview. It still is repetitive, but less drab and a focus on hardware support. SWinxy (talk) 01:57, 2 May 2023 (UTC)[reply]
    Maybe we need a page that tells editors what the difference is between a changelog and a non-changelog list of changes. WhatamIdoing (talk) 02:06, 2 May 2023 (UTC)[reply]
    iOS version history had its tables temporarily removed - it too was a listing of iOS releases, and was in that form for literally over 15 years, until recently when apparently the wikipedia community decided to somehow start enforcing it. it was never enforced until now. this policy is negatively impacting information availability, when with a platform like wikipedia, more information is a blessing not a curse. - Evelyn Marie (leave a message · contributions) 03:08, 2 May 2023 (UTC)[reply]
    That they were only recently removed is interesting. I believe that the interest in applying NOTCHANGELOG was because of the massive pages of the Firefox & Chrome version history pages going to AfD and their wider discussion from outside Wikipedia. Things seem to stay here for a long time either because it's a good idea and need not be challenged, or because nobody wants to go ahead and challenge it, knowing full-well they'll get a lot of pushback. It was inevitable that the policy and these pages were to come into conflict, albeit a decade late on to NOTCHANGELOG's inception. I don't have the numbers for how many other articles were deleted or modified based on NOTCHANGELOG, but I'd say a lot. Enforcement is not consistent, which I blame for why it's been here so long. Doesn't mean it wasn't enforced at all.
    Wikipedia is not the only source of information, and other websites (namely the official changelogs) serve the sole purpose of providing them. I empathize with your point on information accessibility, but information on these changes is not inaccessible unlike the contents of vast swaths of articles reliant on paywalled or hard-to-research topics. Content is excluded all the time because it's undesirable, and I find changelogs undesirable for an encyclopedia. SWinxy (talk) 20:57, 2 May 2023 (UTC)[reply]
  • Support, we already have policies and guidelines that would restrict what types of changelog articles might exist. Take your pick: WP:DUE (relying too much on primary sources when secondary coverage is minimal would eliminate all but the most notable software from having a dedicated changelog article), WP:GNG, etc. This is instruction creep that is wholly unnecessary with all the other ways we could argue against change logs existing. Removing WP:NOTCHANGELOG would simply make any deletion discussions actually focus on what really matters: whether or not an article can be well sourced and not provide undue weight to the subject. —Locke Coletc 02:18, 2 May 2023 (UTC)[reply]
  • Oppose. It's a clear-cut policy that is referred to in deletion discussions when it applies. Proposer does not provide a compelling reason for its removal and in lieu of that, catastrophizes about how it's destroying the encyclopedia (nevermind the fact that the policy has existed for all this time and Wikipedia is still standing). This is forum shopping for an AFD whose direction is displeasing to the proposer. Axem Titanium (talk) 02:34, 2 May 2023 (UTC)[reply]
    This is a massive accusation of my intended purpose for the RFC, and is downright false. I am bad at phrasing things, but I am not "forum shopping for an AfD", and I'm not asking for WP:NOT to be deleted, just that specific guideline relating to software updates, as it is unnecessary. While Wikipedia has flourished, these policies actively shame useful and valuable information from existing on Wikipedia, over some changelog rules. Wikipedia is an information resource, and it is not exactly an Encyclopedia in the typical sense. It has evolved from that into a severely valuable database / collection of information that would probably thrive even more if policies lke these didn't actively prevent articles from existing. Poor articles shouldn't exist, but articles like Firefox version history have been contributed to in the thousands, and tens of thousands for pages like iOS version history.
    There is, in my opinion, no valid reason that warrants deleting sourced, valuable, and important information from a platform like Wikipedia. - Evelyn Marie (leave a message · contributions) 03:24, 2 May 2023 (UTC)[reply]
    "valuable" and "important" are being questioned, though. ~ ToBeFree (talk) 05:51, 2 May 2023 (UTC)[reply]
    You do know that the "pedia" in "Wikipedia" means encyclopedia, right? QuicoleJR (talk) 18:26, 5 May 2023 (UTC)[reply]
    Not forum shopping; Guerillero, who closed the Chrome AfD, said that the AfD !keep votes were against policy and were discounted; and that if people don't like NOTCHANGELOG, they should open an RfC here. This is proper. DFlhb (talk) 05:00, 2 May 2023 (UTC)[reply]
  • Huh? There is no WP:Changelog, it is a redirect that just goes to wp:not. The closest thing I see wp:not regarding this is that wikipedia is not "Exhaustive logs of software updates. Use reliable third-party (not self-published or official) sources in articles dealing with software updates to describe the versions listed or discussed in the article. Common sense must be applied with regard to the level of detail to be included." This is just content guidance; if somehow it is resulting in deletion of those articles I think that it is a process problem rather than a problem with the existence of this guidance. Sincerely, North8000 (talk) 02:37, 2 May 2023 (UTC)[reply]
    i am specifically talking about that software update policy. it is a useless policy that directly contradicts the past behavior of how articles on wikipedia have worked. list articles aren't encyclopedic, but they still have value and merit. same with these changelog pages. - Evelyn Marie (leave a message · contributions) 03:06, 2 May 2023 (UTC)[reply]
    This is just content guidance; if somehow it is resulting in deletion of those articles I think that it is a process problem rather than a problem with the existence of this guidance. Wikipedia:Articles for deletion/Google Chrome version history (2nd nomination) would like a word. —Locke Coletc 06:21, 2 May 2023 (UTC)[reply]
I disagree with that close (but not necessarily with the result) and it is a good candidate for re-review. In essence a supervote, basing such on it being a clear cut policy violation. Perhaps we should reinforce / clarify here. North8000 (talk) 13:56, 2 May 2023 (UTC)[reply]
  • Oppose removal, support clarification. As noted in the Huh? comment above, the content guidance offered by WP:NOTCHANGELOG (which redirects to the section of WP:NOT being quoted) is content guidance, not "thou shalt not have version history articles". It does indicate that an article that's an "exhaustive log of software updates" might not be appropriate for Wikipedia, and I 100% agree with that - duplicating other change lists doesn't seem to be useful, given that those change lists, at least for updates made after the WWW became a thing (and often even updates before that) are available online, and we could just point at them for people curious when some particular less-notable feature was added. Perhaps WP:NOTCHANGELOG needs to more precisely indicate what "Exhaustive" and "common sense" mean. (And perhaps it should suggests putting more detailed logs that aren't exhaustive and overdone into articles for particular releases, if they exist - I don't hink, for example, that iOS version history and iOS 16 both need to have the same detailed information about iOS 16 versions, as long as the section on iOS 16 in iOS version history has to point readers to that article.) Guy Harris (talk) 05:25, 2 May 2023 (UTC)[reply]
    What does this policy add that WP:DUE and WP:GNG don't already cover? —Locke Coletc 06:20, 2 May 2023 (UTC)[reply]
  • Oppose removal: The current wording ("Exhaustive logs of software updates. Use reliable third-party (not self-published or official) sources in articles dealing with software updates to describe the versions listed or discussed in the article. Common sense must be applied with regard to the level of detail to be included.") is perfectly fine and balanced. It more-or-less matches WP:PSTS's recommendations which are important to ensure encyclopedic quality. ~ ToBeFree (talk) 05:57, 2 May 2023 (UTC)[reply]
  • Support rephrase to clarify original consensus (i.e. to restrict the size of version history articles, and not delete all of them). Policies were made for Wikipedia, not Wikipedia for policies! If articles are so bad, and so unencyclopedic, that they need to be removed as a blight on the project, the need for deletion will be a natural consequence of our core principles. In the same vein, we do not need to have a section in WP:NOT that says "Wikipedia is not a site for writing fanfiction" or "Wikipedia is not a site for promoting energy drinks"; someone writing fanfiction or shilling for energy drinks in mainspace will obviously fall afoul of core content policies. On the other hand, if the energy drink turns out to have been notable all along, the existence of a specific WP:NOENERGYDRINKS would serve no purpose other than to confound these normal processes.
Moreover, and perhaps most importantly, the purpose of policy is to provide some reasonable standard by which the project is run, and to correspond to reality. A policy which goes a decade and a half without being enforced, on an extremely prominent page, whose subsequent deletion nomination on the basis of that policy is unanimously rejected, does not correspond to the reality of the project, and it's not clear that it actually reflects what we want to happen. jp×g
  • NOTCHANGELOG sits under IINFO "WP is not a collection of indiscriminate information". I would agree that if there was universal agreement that a detailed or verbatim changelog article was considered indiscriminate information, that we would not need this call out. The problem is that clearly, newer editors have come along and starting added detailed changelogs (before 2011) and thus it was necessary to say "No, these fall under indiscriminate information". And its clear from the relevant current discussions that there are still editors that think detailed changelogs fall outside IINFO. Hence, that part of the policy is necessary still, even though we could point to several other policies that also support removal. --Masem (t) 12:23, 2 May 2023 (UTC)[reply]
  • Oppose removal but strongly support clarification per JPxG and Guy Harris. For evergreen rapid-release browsers, the tables were egregious, as they were impossible to read or browse, and were soon-to-become the largest articles on Wikipedia.
But per my above comment, we should clarify that NOTCHANGELOG is about level of detail, not an absurd GA-like requirement for inline citations. People used to be too tolerant of egregiously detailed changelogs, but we're now overreacting in the opposite direction, and given the tenor of recent AfDs, I'm worried about blunt, careless deletions of salvageable material, which goes against WP:PRESERVE. Remove the tables from Firefox version history, and you have some pretty awful, but salvageable prose. In any other topic area, an AfD would have failed per WP:NOTCLEANUP; just remove the tables, keep the (pretty bad) prose, and let people fix it over time. Another example is iOS version history. Yes, its tables were too detailed. But it also contains hardware support tables, and non-changelog prose. Yet some editors want it AfD'd just because of the tables, as if the article contained nothing else! Why in the world? The Chrome/Firefox version history tables were egregious, but the iOS table were salvageable. Per Guy Harris, we wanted to move them to the main articles on specific iOS versions, trim them to the essential changes, then obviously add secondary sources. I'd rather not do that from scratch! Yet I had to delete them to avoid the risk of another AfD. Same with History of iTunes; tons of room for improvement. Should the tables be deleted? Should they be kept, listing just the version numbers and release dates, but no release notes? Should they include release notes that just cover the major changes? That's something to be discussed on the talk page, not at AfD. And it has a bunch of non-changelog material. Yet I bet if that article got AfD'd, it might pass due to a bunch of WP:VAGUEWAVE votes. Mass deletions don't make the jobs of those (quite few!) of us who work on software articles any easier. Sorry, but I don't see a lot of these AfD voters helping us out with software articles!
I propose we rephrase NOTCHANGELOG to something like: Use reliable third-party (not self-published or official) sources to determine the appropriate level of detail for software changelogs. Copyright violations must be removed, but if changelogs are covered in excessive detail, rewrite them based on secondary sources, or tag them with {{overly detailed}} per WP:PRESERVE. Roughly. DFlhb (talk) 07:36, 2 May 2023 (UTC)[reply]
  • Oppose change to WP:NOT - Wikipedia is an encyclopaedia, not a hobby-site or version-control site. If anything, WP:NOT needs to be reinforced and better defended, as we're being overrun with by-the-numbers or even algorithmic cruft in list-article-form (e.g., lists of destinations of airlines, lists of turns/signs on US highways etc.) that is nothing to do with the basic objective of providing an encyclopaedia that explains things. FOARP (talk) 08:00, 2 May 2023 (UTC)[reply]
    That is a very simplistic definition of what an "encyclopedia" is, not to mention thats not even how its spelled nor is that even true. Encyclopedias contain a lot more information than just very detailed information about a subject, they can also contain lists about subjects you don't think belong. I severely disagree with this opposal because it seems very opinionated and not neutral. - Evelyn Marie (leave a message · contributions) 08:23, 2 May 2023 (UTC)[reply]
    See encyclopaedia. —Locke Coletc 08:26, 2 May 2023 (UTC)[reply]
    Oh. My bad. I didn't realize :( however - what I said to the comment OP still applies - their comment genuinely seems severely opinionated to me. - Evelyn Marie (leave a message · contributions) 08:29, 2 May 2023 (UTC)[reply]
If my opinion on this seems strong to you, it is because I have now spent years trying to deal with the impact of full-on data-dumps into Wikipedia from various databases creating tens of thousands of valueless, unencyclopedic, non-notable articles in violation of WP:NOTDATABASE. Wikipedia should not be a list of minor changes made to a commercial product based ultimately on what the seller of that commercial product says about it. If the fans of a particular commercial product want to go ahead and maintain that kind of list elsewhere, that's fine by me. (ETA: and yes, encyclopaedia is a correct spelling for this Greek-origin word). FOARP (talk) 08:56, 2 May 2023 (UTC)[reply]
Firefox is not a commercial product though? It is free and open source software maintained by a non-profit organization, similar to Wikimedia. iOS is commercial, but is *heavily* covered in terms of both releases and individual features, and general information related to it. - Evelyn Marie (leave a message · contributions) 01:58, 4 May 2023 (UTC)[reply]
  • Oppose removal The hyperbolic language in this proposal makes me very wary. Consider this comment: crucial to the history of software. That is not Wikipedia's purpose. We summarize the history of software (and other things) that are published in other reliable, independent sources. We do not create that history, and therefore a Wikipedia article can never be thought of as crucial, because it is simply a summary of things published elsewhere. We could delete Abraham Lincoln and there would still be hundreds of biographies available about the man. But we won't delete the Lincoln article because it is an engagingly written and highly informative Good article, not an incomprehensible, mind numbing data dump. Similarly, severely notable is a hyperbolic formulation that I have never heard in 14 years of editing. What does that even mean? More notable that notable or something? Hey, if fans of this type of bloated list really like this type of stuff, then they can start "Softwarepedia" with lenient standards. Go for it! Cullen328 (talk) 08:02, 2 May 2023 (UTC)[reply]
  • Oppose Removal. The first pillar of this website, WP:5P1, is that we are an encyclopaedia. We are not an archive site, a database, a changelog or a repository, and content on this site should be in the form of encyclopaedia articles. The entire point of the "What wikipedia is not" policy is to separate out content that might be useful somewhere, but isn't suitable for inclusion in this project due to being out of scope. Most of the arguments in the OP about how the information is useful, has existed for a long time or is linked to from other sites are irrelevant, none of them are good reasons for keeping poor quality, unencyclopedic content (WP:USEFUL, WP:LONGTIME, WP:POPULARPAGE etc.). From a procedural standpoint I would also like to point out that this RFC is poorly implemented, there appears to have been no attempt to follow the steps at WP:RFCBEFORE and come up with a proposal via talk page discussion that has some chance of gaining consensus. 192.76.8.88 (talk) 09:00, 2 May 2023 (UTC)[reply]
  • Comment: Out of curiosity, I decided to peruse the version history (ha!) to see what actual process caused this bulletpoint to be added to the policy. It was this edit from February 2011, with the summary "another important reminder"... citing no discussion whatsoever. I suppose it is still possible for there to have been some consensus or RfC somewhere, but based on this, it seems like somebody just made this up one day and put it into the policy. jp×g 09:05, 2 May 2023 (UTC)[reply]
Archive 35 of this talk page (Sep 2010 to Jan 2011) contains no relevant discussion. Archive 36 does include a discussion in Feb 2011 about rearranging content (in this section), but nowhere does anybody mention release notes, software versions, or anything of the like. That's not to say that it's prima facie invalid, but it does indeed seem that this was a completely off-the-cuff addition and not based on any actual consensus process. jp×g 09:13, 2 May 2023 (UTC)[reply]
That version of the policy was removed [1] and re-added [2] in October 2011, there was discussion about it in archive 37 [3]. The current wording of that section was arrived at via consensus in archive 45 [4]. 192.76.8.88 (talk) 09:17, 2 May 2023 (UTC)[reply]
Thank you for the link. This is interesting. Reading through the discussion in archive 37, it seems noteworthy to me that the IOS version history article is explicitly cited by the participants as an example of an article that should be edited in line with the policy (but not deleted). So, too, is the archive 45 section -- this time about Android version history, which the consensus was overwhelmingly in favor of modifying the policy to allow the existence of. This actually changes my opinion somewhat; if the consensus at the time of writing this section was entirely in favor of such pages existing (and merely that they should be concise), I think it would be preferable to amend the section to reflect this. I may propose an additional RfC option (or make a different RfC once this ends, since a large number of people have already weighed in rather strongly based on the two available choices). jp×g 10:15, 2 May 2023 (UTC)[reply]
Please do (after this one ends). The tables are awful, but editors in recent AfDs treat NOTCHANGELOG as requiring immediate deletion, rather than hacking away the excessive detail and adding secondary sources. I'd bet some people would support AfD'ing History of iTunes, without substantively engaging in discussion about how to improve it (IMO: remove changelogs for minor releases, turn the major version changelogs into prose with secondary citations, and, if we keep tables, have them only contain the version number & release date along with secondary citations, but no release notes). The old Photoshop version history article was only deleted after its most noteworthy contents were merged into Adobe Photoshop. Recent AfD !delete supporters clearly don't support this incremental approach, and ignore the fact that it's much harder to find secondary sources if we don't have these indiscriminate articles as a starting point (as Mozilla is the exception, not the rule, when it comes to having a centralized database of release notes going back to the beginning) DFlhb (talk) 13:52, 3 May 2023 (UTC)[reply]
The idea against change logs was also discussed as early as 2006. Wikipedia talk:What Wikipedia is not/Archive 5 Masem (t) 12:20, 2 May 2023 (UTC)[reply]
  • Support change/clarification. Policy should summarize what is actual practice, not constrain us, and if actual practice is that these articles are accepted, policy should say so. Stifle (talk) 09:29, 2 May 2023 (UTC)[reply]
  • Oppose removal but support clarification per Guy Harris. This is a useful guideline that can be applied incorrectly and/or excessively, but that does not mean it should be removed. Thryduulf (talk) 10:03, 2 May 2023 (UTC)[reply]
  • Oppose - I generally believe that changelog type content does not belong on Wikipedia. If someone wants extensive detail on the minor revisions of a subject, they need to go straight to the source. Even if repealed, I believe other aspects of NOT would still commonly keep the content from being added. Sergecross73 msg me 10:57, 2 May 2023 (UTC)[reply]
  • Oppose removal, support clarification per Guy Harris. I'm positive there are changelog-esque articles that warrant retention - probably including some fairly detailed ones (yes, with or without tables). But true changelogs/patch notes? No, you couldn't meet DUE and suitable secondary sourcing. Nosebagbear (talk) 11:01, 2 May 2023 (UTC)[reply]
  • Oppose I don't think, even in its current state, that NOTCHANGELOG prevents the existence of the articles Evelyn Marie wants to keep. I'd be fine with a clarification but I don't think its necessary. NOTCHANGELOG, as someone says above, doesn't just say "thou shalt not have changelogs", it just means you need to have some thought when writing one, and not indiscriminately include every non-notable update. Snowmanonahoe (talk) 11:49, 2 May 2023 (UTC)[reply]
  • Oppose The focus on "times have changed" misses the mark entirely; if anything, Wikipedia has (rightly) realized that the original pie-in-the-sky "sum of all human knowledge" idea was a terrible one, which is how we ended up with needing all the notability guidelines and what Wikipedia is not language in the first place, and the tightening of standards over the year has been the only reason the project is still somewhat maintainable. If someone is so upset about exhausting changelings with build numbers and other useless to the lay-reader information is gone, it can be hosted on one of the innumerable other specialist wikis that exist, the same way Wikipedia soldiers on just fine without an article on every Pokemon—the WP:ITSUSEFUL stuff can find a home many places that aren't here. No clarification is needed; the focus on secondary sources is in keeping with all our policies and guidelines, which stress primary sources should be carefully used and definitely shouldn't be the guide to article construction. Der Wohltemperierte Fuchs talk 12:41, 2 May 2023 (UTC)[reply]
  • Oppose removal. If an update didn't receive significant coverage, then it's not important enough to include in the article. We hardly need to list every Firefox update, though we can include information about those that change the logo or make drastic changes. Anarchyte (talk) 13:43, 2 May 2023 (UTC)[reply]
  • Oppose removal, support clarifying. We should do what an encyclopedia does: summarize key information. Keeping detailed logs of version of a piece of software is beyond the scope of an encyclopedia. But things like chronicling every single change ever? No. In other words: don't treat software as any different from any other subject. A subject's history should be included in its article, but it shouldn't mention every single little thing that ever happened. Or, if it has a very long history, WP:SPLIT it out to a History of XYZ article (like iOS version history). And, importantly, any changelog-esque information should come from third party sources. I would, however, support adding something to WP:NOTCHANGELOG saying something to the effect of "some articles contain nothing about their version history; others have an entire article specifically on the subject. Use common sense to determine how much information on version history should be included in a given article."
    Now, I want to respond to some of the other claims that have been thrown around. From the nutshell of NOT, "[t]he amount of information on Wikipedia is practically unlimited, but Wikipedia is a digital encyclopedia and therefore does not aim to contain all data or expression found elsewhere" (emphasis mine). With all due respect to those arguing in support of removal, people who think it should contain every bit of useful knowledge ever fundamentally misunderstand the purpose of Wikipedia. The first pillar says that Wikipedia is not... an indiscriminate collection of information, no matter how much supporters try to claim that it is. WP:USEFUL is an argument to avoid for a reason, after all. The first pillar also says that we are not a dictionary, a newspaper, nor a collection of source documents, even though all of those things would be useful.
    Finally, it appears this RfC was started in part as a response to the removal of the table at the bottom of this section in iOS version history. To comment on that specific matter: such detailed changelogs have no place on Wikipedia. Information is not going to be "lost"; it is still in the version history and the original changelogs are almost certainly on archive.org. But even if it were, it is not our job (c.f. it is not our job to promote very deserving charitable causes).HouseBlastertalk 16:41, 2 May 2023 (UTC)[reply]
    @HouseBlaster: No, it wasn't started because of the iOS version history section. I started it because this policy is killing even basic version history articles for no good and/or valid reasons. - Evelyn Marie (leave a message · contributions) 04:40, 4 May 2023 (UTC)[reply]
    It's holding back version history articles because such articles have no place on Wikipedia. They always come from primary sources which would render a Wikipedia article redundant anyway. Any argument for keeping them amounts to ITSUSEFUL or ITSPOPULAR. TheInsatiableOne (talk) 10:20, 4 May 2023 (UTC)[reply]
    I have struck the relevant portion of my comment. I maintain that this section that was a part of iOS version history does not belong on Wikipedia. In other words, I guess my stance on this issue is that history of xyz articles are fine for software, but they should be written in summary style and should not just copy/paste the changelogs from the developers. And they should be notable, meaning they should have WP:SIRS to support their content. I maintain that NOTCHANGELOG should remain a part of NOT, given that apparently editors need to be told not to document every single software change that ever happened to a notable subject. HouseBlastertalk 14:00, 4 May 2023 (UTC)[reply]
  • Oppose removal but support clarification https://en.wikipedia.org/wiki/Wikipedia_talk:What_Wikipedia_is_not/Archive_45#WP:NOTCHANGELOG User1042💬✒️ 17:35, 2 May 2023 (UTC)[reply]
    @User1042 Please provide a rationale for your !vote! Aaron Liu (talk) 19:16, 2 May 2023 (UTC)[reply]
  • Support we must look not at what Wikipedia was intended to be but instead what its actually used for and thats as a centralised store of easily accessed information no matter the triviality of it, WP:CHANGELOG is a hinderince to that new goal and rather than use it to hold back and contain wikipedia we should accept its no longer useful and should be discarded, the quicker we accept Wikipedia is no longer a Encyclopedia and it is instead a generational time capsule the better Popeter45 (talk) 19:48, 2 May 2023 (UTC)[reply]
    I don't think that's how anyone uses it as, if someone wants that they should just use Wikidata. Aaron Liu (talk) 20:11, 2 May 2023 (UTC)[reply]
    Surprisingly, some actually did FWIW. SWinxy (talk) 21:03, 2 May 2023 (UTC)[reply]
    Wikidata is NOT even remotely close to what Wikipedia acomplishes, nor is Wikidata even a time capsule. Wikidata is literally just a contextual data aggregator that just so happens to be part of the same family of wikis as Wikipedia and integrates with it.
    And for the record, there are MANY people who use Wikipedia as a centralized store of easily accessible information, and I am one of them. There's a reason Wikipedia is so damn popular, and it sure as heck isn't because of its supposed encyclopedic nature. - Evelyn Marie (leave a message · contributions) 01:43, 4 May 2023 (UTC)[reply]
    If Wikidata isn't a time capsule, how is Wikipedia one? Isn't Wikipedia also a data aggregator? Can't indiscriminate information be represented with no loss in Wikidata?
    An encyclopedia is a centralized store of easily accessible important information. Aaron Liu (talk) 01:45, 4 May 2023 (UTC)[reply]
    Except Wikipedia is NOT an Encyclopedia anymore, despite what the logo, and guidelines supposedly say. I've been on Wikipedia for over 12 years. It has never been a true to definition encyclopedia for as long as I've been on it, and majority of Wikipedia policies are making people edit the platform less and less.
    There are probably less than 40 editors in this conversation. It is not an accurate representation of how editors feel regarding Wikipedia policies, as a LOT of previously active editors have left the platform due to either policy rules, or aggressive and/or toxic behavior directed at them. And then people wonder why Wikipedia gets less and less contributions on a daily basis.
    To back this up, I just did a comparison of December 2014, to now. Back in 2014, there were 747 million edits. Almost 10 years later that only increased by ~350 million, and the number of active editors has dropped by over 10,000 from its December 2014 number. It is clear that there is something pushing people away from wanting to edit Wikipedia, and I'm going to assume its because of the policies. - Evelyn Marie (leave a message · contributions) 01:49, 4 May 2023 (UTC)[reply]
    "To back this up" should be a reason why you think your explanation is true.
    Could you specify how it isn't an encyclopedia? Aaron Liu (talk) 02:06, 4 May 2023 (UTC)[reply]
    You seem to be arguing "Other stuff exists" here, which is not a starter argument for policy-based decisions. Just because there's isolated content that seems to be counter to the purposes of an encyclopedia, it is only by wide consensus is that actually allowed, and there's a LOT of content that exists in small pockets of WP that only a couple editors may have ever touched. Masem (t) 02:42, 4 May 2023 (UTC)[reply]
    @Popeter45: @Evelyn Marie: Please, read WP:ITSUSEFUL and WP:ITSPOPULAR. Also, for Evelyn, I'm starting to think you should read WP:BLUDGEON. QuicoleJR (talk) 19:10, 5 May 2023 (UTC)[reply]
  • Oppose - and the two example articles listed above are the exact reason we need keep this in place. Jauerbackdude?/dude. 20:04, 2 May 2023 (UTC)[reply]
  • Oppose removal. If you're interested in writing about the history of some software, then go to the software's article, scroll down to the "History" section, and summarize what's written in reliable secondary or tertiary sources. If you want to maintain change logs, maintain them somewhere else. Wikipedia is for summaries of information, not collecting raw data or statistics. Thebiguglyalien (talk) 20:09, 2 May 2023 (UTC)[reply]
  • Oppose The requirement of third-party sources is essential to a general knowledge encyclopedia and should not be removed. Ideally this would be concisely stated as a general principle at a single place, so that we wouldn't need to have controversial ad hoc rules like this one lying around (the complaint that Wikipedia "is dominated by rules experts" in the link above is likely correct to an extent). Until this is accomplished, NOTCHANGELOG should stay, and be interpreted in its most economical and literal sense. Avilich (talk) 00:33, 3 May 2023 (UTC)[reply]
  • Oppose removal - Articles like Firefox version history and iOS version history, at least in their current states, are not encyclopedic. These articles are longer than our article on World War II which is rediculous. Changelogs should not be kept on Wikipedia. Start a wiki on Wikia if people really want this sort of stuff. Nosferattus (talk) 00:54, 3 May 2023 (UTC)[reply]
    iOS version history isn't longer than World War II at all. What the heck are you talking about? iOS version history is 38,000 bytes, compared to WWII's 250,000 bytes. Have you even checked the article recently, @Nosferattus??? - Evelyn Marie (leave a message · contributions) 01:45, 4 May 2023 (UTC)[reply]
    Additionally, Firefox version hisotry isn't bigger than WWII either. - Evelyn Marie (leave a message · contributions) 02:21, 4 May 2023 (UTC)[reply]
    That's just the main article on WWII. If you start getting into all the subtopics, like the articles we have on the many different theaters of the war (like Western Front (World War II)), or the dozens of articles we have on specific battles (like Operation Overlord), or the hundreds of lists (i.e. Lists of World War II topics), and the detailed historical analysis articles like Causes of World War II and Diplomatic history of World War II, I wouldn't be surprised at all if our coverage of World War II was over a gigabyte. Saying that we're covering anything in more detail than World War II is a fairly ridiculous claim; saying we're covering a browser version history in more detail is patently absurd. Ivanvector (Talk/Edits) 06:10, 4 May 2023 (UTC)[reply]
    @Evelyn Marie and Ivanvector: It looks like someone removed the detailed changelog tables from both articles (which I had tried to do myself, but was reverted). Previously, they were both among the largest articles on Wikipedia. I stand corrected. Nosferattus (talk) 12:01, 4 May 2023 (UTC)[reply]
  • Oppose removal. As others have said, the content in changelogs is not encyclopedic; if you want those details, or want a platform on which you can continue recording every update in nicely-formatted tables, you can go to a fandom wiki. I suspect that 99% of the "usefulness" claimed of these articles is strictly dependent on there being exhaustive primary-sourced/copyvio changelogs nicely formatted in tables, and therefore even if NOTCHANGELOG didn't exist, the prosifying and summarizing still necessary to comply with our other WP policies would eliminate engagement with these articles almost as much as deleting them would. JoelleJay (talk) 03:49, 3 May 2023 (UTC)[reply]
    content in changelogs is not encyclopedic You are correct. We're lucky, then, that it's not simply a copy/paste that most editors are suggesting we have for these articles. It's quite clear that these articles are very popular with our readers as well. As of this writing, Windows 10 version history (edit | talk | history | protect | delete | links | watch | logs | views) has over twenty million views. IOS version history (edit | talk | history | protect | delete | links | watch | logs | views) has over eight million views. MacOS version history (edit | talk | history | protect | delete | links | watch | logs | views) has over seven million views. Safari version history (edit | talk | history | protect | delete | links | watch | logs | views) has two million views. Firefox version history (edit | talk | history | protect | delete | links | watch | logs | views) has over one and a half million views. Even the relatively new Windows 11 version history (edit | talk | history | protect | delete | links | watch | logs | views) has nearly a million views (that page was created in the summer of 2021). you can go to a fandom wiki You know the door is always open for you to go there as well, I think you know the way. But it's very clear our readers think these articles are "encyclopedic". Even if you WP:DONTLIKEIT. —Locke Coletc 04:16, 3 May 2023 (UTC)[reply]
    I think the only thing you can conclude from the high view counts is that readers like viewing these articles, not that they're encyclopedic. WP:ITSPOPULAR. Although they're probably high profile targets for google's knowledge panel bots so a decent chunk of pageviews are probably from that. Axem Titanium (talk) 04:56, 3 May 2023 (UTC)[reply]
    I mean the readers would seem to disagree with you. And I don’t know about you, but I’m here to provide knowledge to our readers, not pick and choose what I think is best for them based on some subjective criteria. As for the bot claims do you have any proof for that? —Locke Coletc 05:26, 3 May 2023 (UTC)[reply]
    The simple act of looking at an article, by one reader or millions, does not confer upon the article the mystical quality of being "encyclopedic". Axem Titanium (talk) 06:38, 3 May 2023 (UTC)[reply]
    You know what? I think I’ll take the readers views on this over yours. —Locke Coletc 07:51, 3 May 2023 (UTC)[reply]
    Locke Cole, the reader psychic, able to know the views of every Wikipedia reader through the use of his extra-sensory perception. The 8th Wonder of the World! Axem Titanium (talk) 07:55, 3 May 2023 (UTC)[reply]
    Apparently millions can be wrong just because you just don’t like something, so… there’s that. —Locke Coletc 08:01, 3 May 2023 (UTC)[reply]
    That's an argumentum ad populum. It is possible for a majority to be wrong. TheInsatiableOne (talk) 13:52, 3 May 2023 (UTC)[reply]
    I mean I'll take an argument from that over just not liking something. 🤷‍♂️ —Locke Coletc 14:07, 3 May 2023 (UTC)[reply]
    Not liking something based on our principles decided by community consensus. Aaron Liu (talk) 14:19, 3 May 2023 (UTC)[reply]
    Except, @Axem, an article doesn't have to be "encyclopedic" to exist on this platform, as proven by the thousands if not tens of thousands of articles that exist that probably wouldn't be included in typical "encyclopedias". Wikipedia is a massive database of information, and a lot of Wikipedia's policies aren't actually required rules. They are only guidelines, guidelines that can be followed but if something is severely popular enough to be within the scope of Wikipedia (e.g. something heavily notable), it is typically allowed to exist without much intervention or backlash, something I have seen very, very often in my nearly 12 years of being on this platform. I see a lot of one-sidedness in this entire RFC from very few editors who seem to be interpreting this changelog guideline into something it isn't. This guideline was VERY EXPLICITLY modified to allow articles like Android version history to exist back when it got its current wording. Other articles similar to it are also allowed to exist with no AfDs.
    Not allowing version history articles to exist on the platform potentially allows the ability to hide notable events that happened with software, e.g. controversial additions and/or removals to a software product. Version histories also help teach lessons in not repeating past mistakes. I'm not the best at phrasing things, so I tried, thanks to my girlfriend bringing this argument as well, who additionally isn't a big fan of the way Wikipedia policies operate either, especially this one. Plus, with a platform like Wikipedia, if information included in articles like Firefox version history is removed, what information will there be to find out if e.g. Firefox and/or Mozilla ever go under and the Firefox release history goes with it? Firefox is currently, and has been for a while, losing major marketshare to other web browsers like Chrome, Edge, and Safari.
    So, as the creator of the RFC, I firmly oppose to these opposals based on ancient & archaic Wikipedia policies that do not reflect (in my opinion) the current state of this platform as a whole, and these policies are in my opinion additionally hurting Wikipedia from being able to get new contributors. But, that's a separate subject, and too broad for this specific RFC. - Evelyn Marie (leave a message · contributions) 14:27, 3 May 2023 (UTC)[reply]
    WP:NOTPAPER kind of covers the idea that, unlike a paper encyclopedia, Wikipedia is not constrained to what we can/should print on paper. That being said, it does leave guardrails in place that not everything should be included, but as other editors have noted, we have dozens of articles on truly niche topics, while software like this is used by millions of people around the world, and noting the history of such software over a long period is something clearly our readers desire. —Locke Coletc 14:38, 3 May 2023 (UTC)[reply]
    How is Wikipedia a database? For all purposes isn’t wikidata that instead? Aaron Liu (talk) 15:29, 3 May 2023 (UTC)[reply]
    A database can literally mean anything related to information, from a simple database of data entries, like Wikidata, to a comprehensive source of information, like Wikipedia. Even some game wikis refer to themselves as databases. The term database isn't limited to only one definition, or one use. That's why I said its a massive database of information. You could also argue its a massive cluster of information, with its 4+ million articles. - Evelyn Marie (leave a message · contributions) 01:38, 4 May 2023 (UTC)[reply]
    That's just semantics, really. The common understanding of a database is a uniform layout in which an arbitrary amount of data is stored. Wikipedia is designed to be a public accessible encyclopedia. Not a ledger of entries containing a token amount of information each only kept because some people find it interesting. TheInsatiableOne (talk) 14:18, 4 May 2023 (UTC)[reply]
  • I see no reason why we should misdirect 10-20 million people away from the official and fully updated list of changes to a Wikipedia page that is presumably full of mistakes, omissions and requires unpaid volunteers to maintain. Avilich (talk) 05:06, 3 May 2023 (UTC)[reply]
    I see no reason why we should misdirect 10-20 million people Evidence of people being "misdirected"? presumably full of mistakes And this? requires unpaid volunteers to maintain If it makes you feel any better, we can add Avilich is not required to maintain any changelog articles, in perpetuity. That way you won't feel compelled to accidentally improve or maintain a changelog. But your point belies a truth you don't seem to want to face: some editors (unpaid volunteers) do want to maintain such articles. —Locke Coletc 14:12, 3 May 2023 (UTC)[reply]
    I think you may want to strike your third and fourth sentence. Aaron Liu (talk) 11:38, 4 May 2023 (UTC)[reply]
    It doesn't particularly matter if people want to or not, the fact of the matter is that changelogs are likely to run afoul of not only NOTCHANGELOG but also INDISCRIMINATE. And I'm quite sure some people would want articles filled to the brim with inane trivia (such as a changelog) but just because someone somewhere wants it doesn't mean it needs to exist. TheInsatiableOne (talk) 11:55, 4 May 2023 (UTC)[reply]
And you can't conclude from page views that a huge numbers of readers want to see that iOS 19 or Windows 11 2H38 or... changed the default color used for check boxes from {R,G,B} to {R+1,G,B-1}, so it doesn't argue in favor of the per-minor-release bulleted lists (which often become copyvio magnets). If people really want to see everything new in, say, iOS 16, they can go here or here or here or..., and Apple news sites also have minor-release feature lists as well. iOS version history is currently, as far as I'm concerned, what it should be; the big tables, if they're ven needed at all, could go in the individual release pages. Guy Harris (talk) 05:18, 3 May 2023 (UTC)[reply]
Just because something is convenient or useful or viewed a lot does not mean it is encyclopedic. Plenty of things would get far more views than version history logs if we hosted them: local yellow page directories, how-to guides, weather forecasting, etc. That doesn't make those things encyclopedic. JoelleJay (talk) 20:33, 3 May 2023 (UTC)[reply]
WP:ITSPOPULAR EXISTS. QuicoleJR (talk) 19:13, 5 May 2023 (UTC)[reply]
You should probably read it sometime. —Locke Coletc 19:18, 5 May 2023 (UTC)[reply]
You should probably explain why popularity equals encyclopediarity sometime. Aaron Liu (talk) 20:00, 5 May 2023 (UTC)[reply]
I guess you need to read it too: There are many things that have reached the status of one of the above examples, yet they have never been covered in any published source, and they are nothing more than word-of-mouth. Hint: Many of these changelogs have been covered in reliable sources, so "it's popular" isn't the only reason being given for saying they deserve encyclopedic coverage. —Locke Coletc 04:32, 6 May 2023 (UTC)[reply]
Firstly I'm not sure how that is relevant to what I asked. Secondly, Many of these changelogs have been covered in reliable sources, but little to none of them are listed in many articles involved. Plus, I haven't seen reliable sources on every single detail of changelogs, so if the definition of changelog includes exhaustive, that statement is just false. Aaron Liu (talk) 12:52, 6 May 2023 (UTC)[reply]
Now you know how I feel when someone cites WP:ITSPOPULAR without reading it. As to your question, maybe your understanding of what is encyclopedic is skewed when our readers seem to think the topic is encyclopedic? The better question is how you think it isn't encyclopedic? Plus, I haven't seen reliable sources on every single detail of changelogs For Apple software updates, there are usually at least a few RS for minor releases, with major releases typically receiving wide RS reporting. The same is true for Google Chrome. —Locke Coletc 14:42, 6 May 2023 (UTC)[reply]
It’s not encyclopedic because it’s not an article with weighted points of importance. The minor details have been given undue weight while the bigger changes haven’t been given due weight.
I don’t think there’s much RS for minor things that extend beyond routine coverage. If there is, then that change probably isn’t minor. Aaron Liu (talk) 15:09, 6 May 2023 (UTC)[reply]
Since people are trotting out WP:BLUDGEON, I'll just state that I don't have to WP:SATISFY you. You're wrong, I'm sorry that you're wrong, and I hope someday you figure that out on your own. —Locke Coletc 15:41, 6 May 2023 (UTC)[reply]
Ah, the most convincing of arguments: "Nuh uh!" Although I think this thread stopped being about "convincing arguments" some time ago. As I understand Aaron Liu is saying that popularity isn't related to the question of whether something is encyclopedic, while Locke Cole is saying that WP:ITSPOPULAR doesn't say that. Both of you seem right? Let's move on.--Jerome Frank Disciple 15:47, 6 May 2023 (UTC)[reply]
I don't think you're bludgeoning, you're not repeating the same argument. Aaron Liu (talk) 18:53, 6 May 2023 (UTC)[reply]
  • Comment re WP:ABOUTSELF: Looking at this, WP:NOTCHANGELOG insisting on third-party sources doesn't seem to be supported by relevant policy. The most relevant point I see there is that we shouldn't have articles based primarily on changelogs. RAN1 (talk) 09:43, 3 May 2023 (UTC)[reply]
    You could argue that the primary source would provide WP:ROUTINE coverage of every update. Aaron Liu (talk) 12:05, 3 May 2023 (UTC)[reply]
    WP:V requires that we have third-party sources to have an article about a topic. If we are just using apple.com changelogs to make an iOS changelog, that fails WP:V Masem (t) 12:09, 3 May 2023 (UTC)[reply]
    [citation needed]Locke Coletc 14:14, 3 May 2023 (UTC)[reply]
    Wikipedia:Notability? Aaron Liu (talk) 14:20, 3 May 2023 (UTC)[reply]
    So we just pretend WP:PRIMARY doesn't exist? —Locke Coletc 14:36, 3 May 2023 (UTC)[reply]
    What about it contradicts me or Masem? Aaron Liu (talk) 15:27, 3 May 2023 (UTC)[reply]
    WP:PRIMARY would seem to allow primary sources with care. WP:V does not fail this, as it's still verifiable. —Locke Coletc 16:06, 3 May 2023 (UTC)[reply]
    From PRIMARY "Do not base an entire article on primary sources, and be cautious about basing large passages on them.". (Wp:v used to say, "if there are no third party sources about a topic, WP should not have an article on it",but that's been removed. Masem (t) 16:14, 3 May 2023 (UTC)[reply]
  • Oppose: (updated from "Narrowly oppose") In the abstract, perhaps, it's a little strange to specifically exempt changelogs as WP:NOT—couldn't we just apply WP:PRIMARY or WP:DUE for the pages that overly (or exclusively) rely on primary sources? That said, due respect to supporters, but I think some of the arguments here and in the deletion discussions illustrate WP:NOTCHANGELOG's usefulness.
    There seems to be a near universal appraisal that a page like iOS version history is a fine page—it reads like an encyclopedia page (it's not particularly repetitive; it's mostly in summary style), and it includes many reliable sources. I admit I didn't see the Google Chrome page prior to deletion, but if it did meet those standards, it's unfortunate that its supporters in the deletion discussion didn't stress them. Perhaps others are right and NOTCHANGELOG should be clarified, and perhaps that would better structure these conversations. But, as it stands now, over and over again, these discussions seemed dominated by WP:ITSUSEFUL arguments, even allowing for the RFC drafter's claim of extreme usefulness: Sure, the article isn't encyclopedic in the traditional sense, but Wikipedia has not been an "encyclopedia" in the classic sense since it was conceived, and removing information from Wikipedia shouldn't be encouraged, especially if it has merit / value to existing and is adequately sourced. And besides, don't the page views make it very clear our readers think these articles are "encyclopedic"? (Also—just an aside, but one thing that struck me was the almost passing treatment of the fact that, apparently for some time, the tables at iOS version history were replete with copyright violations?)
    To the usefulness points, I think User:Masem and User:HouseBlaster have the best arguments. As such, I oppose removal.--Jerome Frank Disciple (talk) 13:30, 3 May 2023 (UTC)[reply]
    Here’s an archive of the page a day before it was deleted. I don’t think there’s anything to salvage in here. Aaron Liu (talk) 14:01, 3 May 2023 (UTC)[reply]
    I think maybe ~5% could have been salvaged and turned into a high-level summary style prose overview, which is better than nothing (and it's certainly fun to take a chainsaw to articles in that way, easier than starting from scratch). Depends on whether we favour immediatism or eventualism, but there's no doubt the tables were unacceptable for an encyclopedia and the Chrome/Firefox tables especially, as they received monthly major releases (as opposed to yearly or every few years for all other software) DFlhb (talk) 14:07, 3 May 2023 (UTC)[reply]
    I think that ~5% could have been merged into Google Chrome#History or some other relevant section, but that's not what the AFD outcome went with. If we agree that a prose summary is the way to go, I don't see a need for a standalone article on version history when the main article is right there. Axem Titanium (talk) 16:51, 3 May 2023 (UTC)[reply]
    Wow it didn't even occur to me to check for an archive—thanks (and sorry to put the extra work on you)! And wow ... that's actually a bit more severe than I had imagined. A lot of content without quotation marks is ... straight up quotes, and the number of secondary reliable sources is pretty minimal. Honestly, knowing now what the article was ... and looking at the deletion discussion ... I'm a bit firmer on my oppose.--Jerome Frank Disciple (talk) 14:21, 3 May 2023 (UTC)[reply]
  • Oppose - As this would give carte blanche for reams of trivial and un-encyclopedic software update databases to be created, much to the detriment of Wikipedia's quality as a whole. --TheInsatiableOne (talk) 13:40, 3 May 2023 (UTC)[reply]
    Nobody has suggested removing WP:DUE or WP:GNG, both of which could be used to limit the amount (DUE) or inclusion at all (GNG) of overly detailed changelog articles. —Locke Coletc 13:45, 3 May 2023 (UTC)[reply]
    It is better that we have a policy for this particular use case, as it seems to be a source of arguments. NOTCHANGELOG ought to be expanded upon, which would increase its usefulness. TheInsatiableOne (talk) 13:54, 3 May 2023 (UTC)[reply]
    Well each case will be different, so painting changelogs with a broad stroke like this is both damaging to the project, and damaging to our readers (who as I note above, visit some of our changelog articles millions of times). It's also unnecessary instruction creep, DUE and GNG already prescribe how we should limit article content/topics. —Locke Coletc 14:06, 3 May 2023 (UTC)[reply]
    Not really, if a changelog database gets dumped in here from primary sources then there should be a policy against such a thing. Which is why NOTCHANGELOG needs to be clarified and expanded. Also, my primary concern is that removing it would lead to even more slap fights over changelogs as both sides cite this or that policy or reason for keeping or deleting. We need one decisive policy which on no uncertain terms has a particular ruling, which will prevent long winded debates with no sign of consensus. TheInsatiableOne (talk) 15:03, 3 May 2023 (UTC)[reply]
    then there should be a policy against such a thing WP:DUE and WP:PRIMARY got you. You're welcome. We need one decisive policy which on no uncertain terms has a particular ruling, which will prevent long winded debates with no sign of consensus. If there's one thing I've learned after being here this long, it's that we never truly have a decisive policy on pretty much anything. I sincerely doubt this subject will suddenly break that tradition. —Locke Coletc 15:21, 3 May 2023 (UTC)[reply]
    I'm unconvinced. The fact that the AfD for the Firefox changelog has rattled so many cages indicates that a specific policy ruling on changelogs is necessary. TheInsatiableOne (talk) 15:27, 3 May 2023 (UTC)[reply]
    I think this looks far more contentious than it actually is, because the battle-lines the drawn in the wrong place. In these AfDs, there were a handful of (largely canvassed) !keep votes based on ITSUSEFUL, which framed the debate as "do we want super-long irrelevant changelogs?" But basically everyone agrees that these articles were bad. The Firefox history article was tagged with {{overly detailed}} for years, and no one challenged that tag. The debate would be a lot more productive if it had been framed as "those articles suck; should we follow WP:PRESERVE and tag/boldly fix them, or should we delete?" Clearly the articles are notable. DFlhb (talk) 15:41, 3 May 2023 (UTC)[reply]
  • Oppose removal but support clarification - Wikipedia is not a repository for indiscriminate information on non-notable topics, which ought to have been clarified in the policy in the first place. We don't host pages which are nothing but exhaustive lists of every minor release of software that's not otherwise notable. We shouldn't, but the reason we shouldn't is not because of it being such a log, but because it's information about a non-notable topic. Major release histories for market leaders in a software class that has literally redefined how the world interacts with itself over the past 30 years is WP:DUE relevant background information on that software's development, in much the same way that we currently have a master page and eleven subpages for the manufacturing history of the Honda Civic. NOTCHANGELOG was never intended to be a bright-line rule against hosting this information in any form, it's just advice on how to do it properly. Ivanvector (Talk/Edits) 14:21, 3 May 2023 (UTC)[reply]
  • Support softening/clarification to be clear said policy is not a blanket prohibition on version update lists & articles. What this policy should be for is that for an article on Obscure Open Source Project ABC, don't have a whole section that just copy-pastes the changelog. But something like a version history of iOS or Firefox, software used by zillions? That's fine and very relevant, in the same way that specific car models are relevant, or different versions of the same airplane. It's easy when there's different labels between the Boeing 747-200, 747-300, 747-400, but that just isn't how a lot of modern software works, with big single releases. Rather, many bits of software do continuous rollouts with lots of versions. Further, these versions, down to the month they came out in, can be quite relevant from an encyclopedic context - if you're reading an article on a particular Samsung phone, knowing which version of Android it had is relevant. Finally, I find the tone of some of those in favor of strict deletion troubling, that because they don't find it interesting it means it's not encyclopedic. Don't get me wrong, there's walled gardens of cruft on Wikipedia that need cleaning, but this particular one seems to have reached a "throwing baby out with the bathwater" level. For one famous disputed example, there's a movement to trim back articles on certain very obscure athletes, and I even support culling such articles, but that doesn't mean every article on obscure sixth-division football should be deleted. There's clearly sources and an audience for it, even if I'm not it. The same respect should be extended here. SnowFire (talk) 15:56, 3 May 2023 (UTC)[reply]
  • Support removal, and if not removed then clarification: This policy is being abused by people who pick on articles that need improvement, but that doesn't necessarily qualify them for AFD. Somehow also only certain articles get AFDed under ths policy, while Android version history and others don't get touched (yes, I know they are too good for that), but if you argue one AFD with this, then you would have to be consequent and delete them all. And another question: What is the difference between a changelog and a page about the history of a country? One describes the changes in a country, the other the changes in a software. I am pretty sure nobody here would come and say We should remove History of the United States, but in general it's a changelog of the US. Yes, I know that the policy only goes for software, but why? Again, what is the difference between a changelog of software and the history of something else? If you compare History of the United States and Firefox version history, they aren't that different, only one has more pictures than the other and is longer, while the other one is up for AFD for some time. Both group stuff by certain epoches, both generally list a lot of information nobody wants to read. That's why they aren't in the main articles. I don't expect anyone to care for the history of Firefox, same as I don't care for the history of the US. But obviously someone does care for both, or we wouldn't have neither this discussion here nor the articles themselves. Why treat them differently? It doesn't make any sense.Qxyz123 (talk) 18:47, 3 May 2023 (UTC)[reply]
    Articles being too good and but if you argue one AFD with this, then you would have to be consequent and delete them all are directly contradictory. The difference between changelog and history is that a changelog lists every single thing no matter how big or small, which is what the Firefox article currently does. Plus, the Firefox article has long, extremely template-y prose sourced with primary sources while the US article has a ton more variety in the prose and has only 18 primary sources out of 300-something. Aaron Liu (talk) 19:15, 3 May 2023 (UTC)[reply]
The (sub-)policy in question is opposed to "Exhaustive logs of software updates.", not to anything that lists software updates, and further states "Use reliable third-party (not self-published or official) sources in articles dealing with software updates to describe the versions listed or discussed in the article. Common sense must be applied with regard to the level of detail to be included." History of the United States doesn't indicate that some Postmaster General got married two years into their term if their spouse isn't particularly relevant to the Postmaster General's job (if the spouse was the CEO of a parcel delivery company, that might be worthy of note, but if they're a teacher at a local school, not so much). Similarly, is it really noteworthy that iOS 16.2 included "New Home app splash screen highlighting.", as this version of iOS version history noted? As for why it specifically calls out "logs of software updates", that may because software updates are a topic that attracts very long lists that might be worthy of trimming, to an extent that national histories don't, so having that particular sub-policy may be a useful further note to avoid that sort of thing. Guy Harris (talk) 19:25, 3 May 2023 (UTC)[reply]
I understand that, but then I don't get why everyone tries to delete these articles instead of improving them. Finding sources for the important changes is possible, and cutting the little changes (like the fact that some version added support for font-stretch, whatever that is) too. It should be clarified that WP:NOTCHANGELOG should not be used to delete every changelog simply for being a changelog. And thanks for explaining the reason behind the policy to me. Qxyz123 (talk) 20:16, 3 May 2023 (UTC)[reply]
In most cases, improving them is best started by a WP:TNT approach - maybe draftify the existing article to have sources at hand, but rewriting to focus on good quality prose than just dumping tables out. Masem (t) 14:47, 6 May 2023 (UTC)[reply]
  • Oppose removal but would support workshopping some rewriting for more clarity. In general, a contextless list of every software update is a bad idea. However, I also think the lack of proper guidance is leading to people blindly using the rationale without thought as to where and when it applies; well-written encyclopedic prose that covers the history of a topic is clearly outside of the scope of the intent of the policy. That requires more clarification, not removal.--Jayron32 19:23, 3 May 2023 (UTC)[reply]
    Most software history articles lack prose and inline citations, and contain cruft; the core issue is whether they're TNT-worthy or not. Post AfD snow-close, some called for deleting the iOS article. Yesterday, I worked on it for roughly an hour, and now people uphold it as acceptable. It met WP:GNG and WP:LISTN ([5][6][7][8]). Took an hour to fix. Shouldn't have been at risk of deletion, yet it was. That's the problem.
    I removed the iOS tables, but the goal, per Oct. 2022 consensus, is to move them to the articles on each iOS release. They contain cruft like "new splash screen" (per Guy), but also encyclopaedic material like iOS 5.0 adding tabs and Reading List to Safari, which are not covered in iOS 5. Deleting without merging would be disruptive. WP:NOTSTATS explicitly tolerates articles like this, this, and this, as a way to unclutter the main articles. That's what iOS version history was, and the tables met WP:LISTCRIT if trimmed of cruft like new splash screens. Same with History of iTunes and Safari version history, split off to unclutter the main articles: the tables meet LISTN and LISTCRIT, and need a good trim and citation work, but they contain both cruft to be cut, and encyclopedic info to be expanded (in prose or not, that's just a presentation issue). There, the core issue is: when a table contains encyclopedic material and cruft, do we delete the table/article, or just the cruft? DFlhb (talk) 22:17, 3 May 2023 (UTC)[reply]
    The iOS page still has no sources for the 1400 words spanning the iOS 7 through iOS 12 sections as well as wide swathes of the preceding and succeeding sections. Importantly, there are also numerous citations to publications (MacWorld, Computerworld) whose operations in media and technology marketing are central to their parent market intelligence and demand generation company, which absolutely conflicts with their neutrality, independence, and DUENESS (and that's without even considering that MacWorld/IDG also hosted the product launches for iMac, Mac OS X, iTunes, iPhone, etc.). Surely a company that describes itself as a technology and intelligence company that blends its proprietary datasets of two billion market-points with a one-of-a-kind network of 350 million technology buyers to drive performance for the world’s leading B2B brands and [creates] engaging content that accelerates purchasing and deepens engagement, that boasts 75% of Forbes' Top 100 Digital Companies [among its] customers, has a financial interest in publishing as much info as possible, as frequently as possible on target brands to increase its data-mining capacity and drive demand for its clients? JoelleJay (talk) 01:32, 4 May 2023 (UTC)[reply]
    MacWorld, ComputerWorld, etc, are accepted sources. They have been since Wikipedia was created. I'm pretty sure it doesn't matter if they're not 100% neutral if they give correct information. - Evelyn Marie (leave a message · contributions) 01:40, 4 May 2023 (UTC)[reply]
    The goalposts keep shifting. You may not want to venture out to WP:TVRS and WP:VG/RL. DFlhb (talk) 02:55, 4 May 2023 (UTC)[reply]
    Sources can be reliable but not third-party, as required by the policy. JoelleJay (talk) 17:07, 4 May 2023 (UTC)[reply]
    Yeah, its inappropriate to say field-specific magazines like MacWorld cannot be used for third-party sourcing of change log info. If Apple produced its own magazine and that was the only other source used, yes, that's a problem, but in very broad terms, in fields which involve reviews and commentary about consumer products, we do not discount sources that are focused on one specific aspect. Masem (t) 03:14, 4 May 2023 (UTC)[reply]
    They are not just "focused on one aspect". Foundry/IDG is only a consumer data mining/martech firm; its editorial brands (the magazines) are published specifically for content marketing purposes: to harvest buyer intent data and drive demand for the products they cover.

    We help technology marketers and agencies drive awareness and achieve their objectives by engineering the right combination of media solutions – advertising, demand generation, content, research, and events.
    Our model is based on data that’s generated, with full consent, from our award winning editorial brands.

    Your content will be hosted on the owned and operated, award-winning editorial sites of ours most relevant to your product or service offering

    They directly profit from iOS sales, not just through native advertising (Showcase your message to a tailored and engaged audience through seamless native integration on Foundry’s editorial sites), direct sales through affiliate links ($16M spent annually on technology purchases via Macworld), and demand generation within the magazines (proactively nurtur[ing] prospects in buying mode with content designed to influence decisions); but also collecting and selling intent signals etc. from MacWorld. To achieve the latter, they have to maintain extremely high consumer engagement by producing as much exhaustive coverage as possible. Are they reliable for verification of details? Yes, just like Apple itself is. Is the extent of their coverage independent of Apple? No. Does NCORP consider them third-party? No (Related persons include organization's personnel, owners, investors, (sub)contractors, vendors, distributors, suppliers, other business partners and associates, customers, competitors, sponsors and sponsorees (including astroturfing), and other parties that have something, financially or otherwise, to gain or lose. JoelleJay (talk) 17:04, 4 May 2023 (UTC)[reply]
    I know we have some areas where the sources are very closely tied to the topic (in a financial way) that they become unreliable...the cryptocurrency area is rife with these. But you are definitely overanalyzing the NCORP aspects here. Eg the WSJ depends on subscribers to its business news coverage, so by your logic, we could never use the WSJ for a source on business matters. Works like Macworld are fully reasonable to use for iOS news items. Masem (t) 17:34, 4 May 2023 (UTC)[reply]
    What? The WSJ does not publish stories on products with the stated purpose of increasing demand for those products. Its business model is not built on extracting consumer purchasing intent through its own sales of products it covers and then selling those data to the product manufacturers. The excerpts I quoted above aren't from some "advertise with us" section of Foundry/IDG; their home page literally says

    Welcome to Foundry
    We’re an organization that generates and innovates with data, to drive demand for technology marketers everywhere.

    The WSJ (or Dow Jones) does not style itself as first and foremost a martech company aimed at Connecting tech buyers and tech sellers. JoelleJay (talk) 21:47, 5 May 2023 (UTC)[reply]
    This discussion probably is beyond this discussion - maybe over at RS, but I can tell you that just because a magazine or other work readily accepts advertising from the same types of products they cover doesn't make it unreliable for our purposes. Otherwise, this would affect a huge number of articles, such as films that heavily using The Hollywood Reporter and Variety, both works that depend on a lot of advertising from that industry. Masem (t) 00:31, 6 May 2023 (UTC)[reply]
    I don't see how you can read what I've quoted above and distill it to merely "readily accepting advertising"?? They're not just running ads, they are using content written in their editorial brands to influence demand. And anyway, NCORP makes it very clear that trade magazines are almost never usable for notability due to independence issues, so even if MacWorld wasn't a martech scheme it is not considered a third-party source for NOTCHANGELOG purposes except in rare circumstances. The only articles that would be affected by this are ones where trade mags are being used to establish notability of an org (which is already disallowed by NCORP) and version history articles that cite only trade mags for their descriptions of changes (disallowed by NOTCHANGELOG). JoelleJay (talk) 21:40, 6 May 2023 (UTC)[reply]
    This is my industry (zero COI here), and this "martech" stuff is just not true. You're applying a lay and simply uninformed interpretation of "demand generation". "Demand gen" means things like webinar signups, email list signups in exchange for free ebooks or free whitepapers, etc. That's the stuff you land at when you click the ads on their sites. It has nothing to do with the content on macworld.com.
    On media outlets most people browse, the ads lead to clothing brands, dropshipped Amazon trash, and so on. On outlets that have non-broke visitors (Bloomberg, WSJ, or the Foundry sites), the ads lead to whitepapers and other stuff meant to lead to B2B (corporate) purchases. That's all the Foundry stuff refers to. None of this criticism is credible, and you don't need to hang your arguments on this to argue for NOTCHANGELOG, which clearly enjoys consensus. — DFlhb (talk) 22:38, 6 May 2023 (UTC)[reply]
    You're wrong. Again, the clear example where trade magazines should not be used is in cryptocurrency, as nearly all magazine owners have clear COI and want to promote one type of coin over another, and as such we immediately doubt all but a few works. I know in more industrial trades, that there are magazines that accept articles written by anyone in the idustury, and as such you can have a major supplier to that industry write a favorable article to draw sales to that supplier, and that's another reason to do that. As DFlhb points out, that's not at all what happens at MacWorld or similar tech magazines. They may accept advertising from Apple or other major suppliers, but their magazine content is written by their staff absent any other drivers. Thus they are valid sources. Masem (t) 13:49, 7 May 2023 (UTC)[reply]
    Okay, full disclosure: I didn't know what "martech" meant. I looked it up, and I thought to myself, "Ah, yes, marketing technology. A portmanteau. Of course. Very clever." ... but then I read the longer definition and realized I still don't really understand what it means.
    I mostly understand the circular issues JoelleJay has pointed out—that a source like MacWorld generates content on products that itself drives demand for the products discussed therein, and then profits from direct advertising and through affiliate links (like Wirecutter?). I don't hope to understand it completely, but I do have one question:
    Does removing/retaining NOTCHANGELONG impact the question of whether sources like MacWorld are reliable? (As Masem mentioned, I'd think that'd be an issue for a WP:RS discussion, but I get the sense from JoelleJay that there's a connection between the policies). (In short, I'm trying to figure out whether I need to reevaluate my survey participation here.)--Jerome Frank Disciple 14:32, 7 May 2023 (UTC)[reply]
    NCORP doesn't make a distinction in which trade magazines are not regarded as reliable While feature stories from leading trade magazines may be used where independence is clear, there is a presumption against the use of coverage in trade magazines to establish notability.
    Again, the main problem is not that the coverage is not reliable or unbiased, it's that, much like info directly from the manufacturer, the existence of the coverage is not indicative of noteworthiness (or PROPORTIONAL merit). That is because the company is not fully independent of Apple in the sense expected by NCORP: it has a vested interest in the demand for Apple products and directly influences it with its coverage, a major business model is harvesting consumer data via engagement with its editorial brands (which in turn incentivizes publishing more articles--and when you only cover one topic that means going deeper into increasingly minor details), and it has (historically?) benefited from exclusive access to Apple news (such as the stevenotes and other product launches at its events); and these factors result in indiscriminate, routine coverage of every Apple development regardless how trivial. JoelleJay (talk) 01:19, 8 May 2023 (UTC)[reply]
    To me, MacWorld doesn't establish notability not because any of that (partially because of DFlhb's claim that demand generation is not writing articles), but because it's routine coverage. Aaron Liu (talk) 01:21, 8 May 2023 (UTC)[reply]
    I don't think that's the problem with MacWorld. My problem is they offer routine coverage of every iOS release. Aaron Liu (talk) 14:14, 7 May 2023 (UTC)[reply]
    I'd estimate rough ~60% of the iOS tables could be sourced exclusively to third-party, non-Apple-dedicated outlets (i.e. not Macworld), to articles that aren't just raw blockquotes of Apple's changelogs. I've just made an edit to iPhone OS 2 to demonstrate (see the last two versions of the table, notice, zero Apple-specific sources like Macworld). NOTCHANGELOG introduces two restrictions: exhaustiveness, and sourcing. The Chrome/Firefox tables are straightforwardly forbidden by the sourcing criterion, but IMO only the exhaustiveness criterion could forbit the iOS tables. For iOS, sourcing (& Macworld) are red herrings (detailed independent sources exists, just aren't cited inline). Dealing with the iOS tables would require us to clearly define what we mean by exhaustive, or to define what "routine" means when it comes to changelogs, which I hope we can do once this RfC finishes. I think banning version tables altogether should be considered, since anything else may leave too much of a gray area. edit: Jerome, I hope this addresses your question — DFlhb (talk) 14:38, 7 May 2023 (UTC)[reply]
    I appreciate the time and the explanation! I feel I can keep my !vote with a fair amount of confidence. Thanks,--Jerome Frank Disciple 18:50, 7 May 2023 (UTC)[reply]
    going all the way to ban all version tables is a very slippery slope to removal of alot of wikipedia that if you feel thats the only way to keep NOTCHANGELOG really shows just how bad NOTCHANGELOG really is Popeter45 (talk) 23:16, 7 May 2023 (UTC)[reply]
  • Oppose removal. The policy is fine, and doesn't prevent the existence of articles like Firefox version history, provided they follow the guidance as written. Barnards.tar.gz (talk) 12:00, 4 May 2023 (UTC)[reply]
  • Oppose removal This policy is crucial in preventing an enormous amount of fan cruft from being added to the encyclopedia. :3 F4U (they/it) 15:25, 4 May 2023 (UTC)[reply]
  • Oppose removal A history section in a software article supported by reliable sources is a good thing, a big list indiscriminate notes is not. -- LCU ActivelyDisinterested transmissions °co-ords° 19:38, 4 May 2023 (UTC)[reply]
  • Oppose - If clarification is needed, that can be done by editing the guidance but the heart of the matter, which is we should not be a detailed dump of change logs is something that should be applied to any all software history articles. -- Whpq (talk) 14:38, 5 May 2023 (UTC)[reply]
  • Oppose removal, support drastic shortening of the iOS and Firefox version history articles, like by a factor of 10 or something. Bug-by-bug notes are ridiculous.--GRuban (talk) 16:02, 6 May 2023 (UTC)[reply]
  • Oppose removal pages consisting of lists of features of each release of a piece of software are not encyclopedia articles and don't have a place in Wikipedia. The iOS and Firefox pages should be either removed or rewritten to be actual encyclopedia articles about the histories of those products. Hut 8.5 17:08, 6 May 2023 (UTC)[reply]
  • Oppose removal. Although the circumstances of this sentence's addition to the policy are not very inspiring (as noted above), it is a valuable guardrail in keeping us focused on encyclopedic content, and summing up all human knowledge rather than simply dumping information. Nothing wrong with people trying to workshop/clarify the language a bit further, but it seems fine as it is. -- Visviva (talk) 20:34, 6 May 2023 (UTC)[reply]
  • Oppose removal. Software changelogs are primary sources, and it is not the purpose of an encyclopedia to reproduce primary sources . Our articles must be based essentially on secondary sources, summarizing the important aspects of our subjects as recognized by these sources. Important changes to software can be part of our coverage of a topic, but this includes only the changes recognized as important by reliable secondary sources. Moreover, changelogs are probably copyright violations if they are copied substantially verbatim form the developers' changelogs. Sandstein 07:29, 8 May 2023 (UTC)[reply]
  • Oppose removal. I find the apparent argument that Wikipedia is somehow not an encyclopedia to be almost insulting, honestly. casualdejekyll 15:47, 8 May 2023 (UTC)[reply]
  • Oppose: The current policy is grounded in WP:RS and makes clear that unimportant, non-notable software updates do not belong in a Wikipedia entry merely because they exist. voorts (talk/contributions) 22:00, 8 May 2023 (UTC)[reply]
  • Support removal per Locke Cole or Support clarification per Guy Harris and JPxG. I'd like to add to my comment that I've long held this is but one of the many ever increasing number of extraneous things in the NOT policy that keep growing into a very WP:CREEPy pile of unimportant or trifling things the pedia might not be about. The only thing useful about them is so that others have something "just a little bit stronger" than the basic policy we already have to point to in arguments so they can say, "see, says exactly right here!". Apparently, it is working pretty good for this ill-formed purpose, because the complaint about the OP appears to be that people are not actually correctly reading/applying the policy, but just saying, "see, it says not changelog". Huggums537 (talk) 02:14, 9 May 2023 (UTC) Updated comment on 22:24, 10 May 2023 (UTC)[reply]
  • Clarify in the spirit of WP:PRESERVE Benjamin (talk) 08:08, 9 May 2023 (UTC)[reply]
  • Oppose removal, we shouldn't be replicating primary source changelogs. We can of course cover software changes, in their own articles in some cases, or as part of larger articles, based on secondary independent sources. CMD (talk) 15:58, 10 May 2023 (UTC)[reply]
  • Yeah, I guess so. A redirect is not a policy, and if it leads to a policy (some) people will take it as a policy. It kind of implies that changelogs are prohibited by our core rules. They're not. Should they be? Search me. But if it's debatable, it might be OK for a guideline but not a policy. Rules are supposed to codify general usage, usually. Probably what we need here is making WP:NOTCHANGELOG into a proper article, couple paragraphs explaining specifically what the problem is with changelogs specifically. Looks like there's plenty good arguments above, save them and put then in a page. Keep it as an essay, or run RfC to promote it to a guideline (risky but might work) or to aa policy (good luck with that).

    The telling argument would be the balance between those readers -- remember them? -- would find the material useful vs those would find it makes the article harder to read, I would think. Remember, articles such as iOS version history will only be accessed by people who have deliberatly done so. I can't guess why a person would do that, but you'd think that since they have, some non-trivial percentage would want really really detailed info. Right? If the clutter makes the info too dense for other readers to read handily, that's an opposing date point. We'd have to make an educated guess I suppose, but that's hardy uncommon. Sounds like something to debate, rather than something to bludgeon yoyr colleages with.

    Serve the reader. That is our remit. The rest is mostly noise. Herostratus (talk) 02:05, 11 May 2023 (UTC)[reply]

    Moved from the "move to fandom" proposal as this appears to be meant here. Aaron Liu (talk) 02:13, 11 May 2023 (UTC)[reply]
Oppose removal as good policy. Wikipedia shouldn't cover changelogs or every update. In the interest of WP:DUE weight, we should cover releases in proportion to their cultural impact. Shooterwalker (talk) 02:57, 11 May 2023 (UTC)[reply]
Oppose removal Constant with our core policies such as WP:INDISCRIMINATE. That there are people, such as the op, that are convinced that Wikipedia must contain there data dumps because they are "cited and referred to by many, many people" shows the necessity of such a policy existing. Much of the content that has been removed using this policy, that the op is complaining about, was indiscriminate and didn't belong here. Cakelot1 ☞️ talk 19:53, 19 May 2023 (UTC)[reply]
Just a technical note: WP:INDISCRIMINATE, and by extension WP:NOT, aren't "core policies". Also, before you even think about saying they are linked in the five pillars at WP:5P1, just remember that WP:OWNERSHIP, WP:EDITING, and WP:COPYVIO are linked at WP:5P3, but that doesn't make any of them "core policies". Likewise, Wikipedia:No personal attacks, WP:EDITWAR, and WP:DISPUTE linked in WP:5P4 are all useful explanatory policies, but it would be ridiculous to consider every little explanatory policy that is linked in the five pillars as a "core policy", especially ones for dealing with minor side issues not really related to the pillar itself or a major part pf building the encyclopedia, such as OWNERSHIP or DISPUTE. Huggums537 (talk) 02:11, 20 May 2023 (UTC)[reply]
WP:NOT is a core content policy, alongside V, NOR, and NPOV, not because its listed at 5P, but because its been one of the standard bars for content. Masem (t) 02:15, 20 May 2023 (UTC)[reply]
I'm not seeing that in the essay I linked to. In fact, I'm seeing NOT listed in the infobox under Other along with the BLP policy, and oddly enough the image use, and title policies. Perhaps you can point me to somewhere else saying what you are claiming? Huggums537 (talk) 02:25, 20 May 2023 (UTC)[reply]
Also, I just now happened to notice that WP:CONPOL shows the infobox the exact same way, and this is a policy overview, not just an essay, so it seems to be much stronger evidence to support what I'm saying. as well as what the essay is saying. The essay has been saying it since 2003. and nobody has been disputing it other than yourself apparently. Huggums537 (talk) 02:42, 20 May 2023 (UTC)[reply]
Even if NOT is not a core content policy (though I think in practice most consider it as such), it still holds great weight in evaluating content issues, just as BLP when those types of pages come up. WP:NOT is not a guideline, so should be followed as closely as possible. Masem (t) 02:48, 20 May 2023 (UTC)[reply]
It was just a small technical note and not anything against the argument. Aaron Liu (talk) 02:50, 20 May 2023 (UTC)[reply]
Thanks for saying this, but Masem knows the back story with me, and he is defending the policy because what might appear to be an innocent technical note could also very well be an insidious plot to undermine the very fabric of what some believe to be the most sacred of guiding principals that will one day eventually be the salvation of Wikipedia. God forbid that should ever happen because we are still waiting for the saviour to come... Huggums537 (talk) 03:13, 20 May 2023 (UTC)[reply]
It's not a core content policy, it's a normal content policy. This is clear in the {{Content policy list}} template transcluded in the essay. Aaron Liu (talk) 02:47, 20 May 2023 (UTC)[reply]
Something hilarious I just noticed is that even WP:NOT uses this template. Haha. Too funny. Huggums537 (talk) 08:23, 20 May 2023 (UTC)[reply]
Yes, it should be removed
The WPNOT essay pieces are making this encyclopaedia worse, due to their legalistic over reliance by deletionists. It would be far better to resolve these issues through case-by-case judgement; rather than by uniform rules that will inevitably result in poor outcomes, as appears to be happening here.
It is a shame other editors feel the need to sabotage the utility of WP as an information source for trivialities Jack4576 (talk) 14:27, 22 May 2023 (UTC)[reply]
And what about deletionism? Both deletionism and inclusionism are regarded as valid and NOT is basically the core of deletionism. You appear to be on a crusade against deletionism for no apparent reason. Since its start Wikipedia has never been meant to be an WP:INDISCRIMINATE collection of information, that would be Wikidata not Wikipedia.
Also, NOT is a policy, not a collection of essays. Aaron Liu (talk) 14:37, 22 May 2023 (UTC)[reply]
Wikipedia is not supposed to be an information source for trivialities. QuicoleJR (talk) 14:43, 22 May 2023 (UTC)[reply]
Jack, accusing other editors of sabotage is a violation of WP:AGF. It's fine if you privately think that's what's going on, but unless you have evidence in the form of diffs, please don't make accusations. You should strike that whole sentence. Valereee (talk) 15:35, 22 May 2023 (UTC)[reply]
I think this is an attack on words. I feel like Jack was using strong language to describe strong feelings about how he feels the utility of triviality is being handled by some editors on here. Just like if I say you're killing me with these baseless accusations of violating AGF doesn't mean I literally accused you of attempted murder. Huggums537 (talk) 17:19, 22 May 2023 (UTC)[reply]
CIVILITY is about not using strong languages and AGF is about not having strong feelings that most editors are sabotaging deliberately negatively impacting the encyclopedia. Aaron Liu (talk) 17:24, 22 May 2023 (UTC)[reply]
@Aaron Liu, Wikipedia is also WP:UNCENSORED meaning that the more civil thing to do is to try to understand each other rather than slap them in the face with warnings just for using strong language. If I say that I sometimes sabotage myself from having good things it does not mean I have intentionally or deliberately done something wrong to myself. If you are assuming that other editors are making use of words in such a way that the words are suggesting the intentional or deliberate wrongdoing of others, when the words may not be, then maybe you are the one not practicing civility or assuming good faith... Huggums537 (talk) 18:17, 22 May 2023 (UTC)[reply]
If you say you sometimes sabotage yourself, you are making a statement about yourself, to begin with. Talking about self-sabotage is not the same as accusing others of sabotage of Wikipedia. I am really surprised to see you arguing that it is. Valereee (talk) 18:19, 22 May 2023 (UTC)[reply]
Oh, for pete's sake! I thought this little discussion was over, but then I saw this. Ok, fine. If I say you sometimes sabotage yourself from having good things it doesn't mean I'm accusing you of intentionally or deliberately doing something wrong to yourself. Likewise, if I say deletionists sabotage us from having things, it does not mean I've accused them of intentional or deliberate wrongdoing. Huggums537 (talk) 01:49, 23 May 2023 (UTC)[reply]
In other words, I could also say deletionists rob us of articles we would like to have, but that doesn't mean I have literally accused anyone of robbery. It is simply language to describe feeling deprived. Huggums537 (talk) 01:53, 23 May 2023 (UTC)[reply]
Anyway, this is all off topic so I am quite finished here. Huggums537 (talk) 01:59, 23 May 2023 (UTC)[reply]
(edit conflict) I don't like issues over semantics either, but the definition of "sabotage" does include proactive, malicious intent. Self-sabotage is an extension that adds "subconciously" to that. Meanwhile, rob of means deprive, which has no embedded malicious intent, though it does have a insufficient negative connotation. Aaron Liu (talk) 02:00, 23 May 2023 (UTC)[reply]
Think about it this way, deletionists are part of "us", yes? So, in a manner of speaking, if I say they sabotage "us" from having things, could I not also be speaking of self sabotage? Huggums537 (talk) 02:14, 23 May 2023 (UTC)[reply]
That depends on how big of a self one has. While some (like me) do practice nosism, that's only a small minority, and even with AGF in place it should be striked. Aaron Liu (talk) 02:31, 23 May 2023 (UTC)[reply]
Haha. Well, we'll see what happens when Jack gets unblocked. Like I said, this is all off topic, and I was done here, but saw the edit conflict, and responded. Have a good one... Huggums537 (talk) 02:35, 23 May 2023 (UTC)[reply]
I understand hyperbole. Following up The WPNOT essay pieces are making this encyclopaedia worse, due to their legalistic over reliance by deletionists. It would be far better to resolve these issues through case-by-case judgement; rather than by uniform rules that will inevitably result in poor outcomes, as appears to be happening here.
with
It is a shame other editors feel the need to sabotage the utility of WP as an information source for trivialities does not look like hyperbole to me. It looks like impugning the motives of other editors. Valereee (talk) 18:17, 22 May 2023 (UTC)[reply]
I guess I will have to agree to disagree. If editors are not allowed to have opinions about inclusionism/deletionism and by extension inclusionists/deletionists without it being considered a personal attack, then civility and censorship rules might as well not even apply. Huggums537 (talk) 18:46, 22 May 2023 (UTC)[reply]
You can have an opinion. You just can't say the editors who disagree with your opinion are trying to sabotage the project. If you want to privately think that, fine. You can even call it wrongheaded. Saying other editors are intentionally trying to damage the project requires very convincing evidence. Valereee (talk) 18:52, 22 May 2023 (UTC)[reply]
You might very well be right, but we still haven't heard from them whether that is in fact what they were saying or not. All we have to this point is us arguing [speculating] about whether their words were an intentional accusation or something far less sinister. Huggums537 (talk) 19:01, 22 May 2023 (UTC) Updated on 21:06, 22 May 2023 (UTC)[reply]
Which is why she asked for striking instead of assuming bad faith. Aaron Liu (talk) 19:23, 22 May 2023 (UTC)[reply]
I just think it is premature to ask for striking without clarifying the intention behind the comment from the actual author of it since it is also possible to interpret it as something other than just being bad. Huggums537 (talk) 21:43, 22 May 2023 (UTC)[reply]
I also realize that my response about it being "an attack on words" was also premature considering that also could have been interpreted as something not as bad... Huggums537 (talk) 21:46, 22 May 2023 (UTC)[reply]
Ok, well none of this matters now since this was apparently not an isolated incident, and Jack got blocked, plus it looks like he's been on the fast track to an indef in the same way I was several years ago. I hate to see this happening to smart editors that we really need to have on board, and I hope he will get hip and wise up real quick. Huggums537 (talk) 00:41, 23 May 2023 (UTC)[reply]
Removing perfectly encyclopedic content sure seems damaging to me. But I stopped caring about this clusterfuck when people were dropping WP:BLUDGEON (here) and WP:POINT (at the RFD) accusations. —Locke Coletc 19:04, 22 May 2023 (UTC)[reply]
We're almost in circles here, but that depends on "encyclopedic". In my view this stuff isn't encyclopedic. Aaron Liu (talk) 19:21, 22 May 2023 (UTC)[reply]
  • Oppose change in NOT - I really don't see how not including massive dumps of version info is somehow "detrimental to the health and prosperity of Wikipedia as a platform". Like others have suggested, if you want to cover software history, dig up some secondary RSes which discuss important changes over time, summarize that info in the article as comprehensible prose, and then be done. -Indy beetle (talk) 19:16, 23 May 2023 (UTC)[reply]
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.

I've started a discussion on the WP:NOTCHANGELOG redirect itself, interested editors should leave a comment there. —Locke Coletc 14:40, 3 May 2023 (UTC)[reply]

  • Jayron32, regarding this comment in the above referenced discussion, I was talking about the emerging consensus related to clarifying things that people seem to be wanting. I thought that was obvious, but I guess I should have made it more clear. In other words, I never said there was emerging consensus to have it removed. Thanks. Huggums537 (talk) 08:58, 18 May 2023 (UTC) Updated comment on 09:17, 18 May 2023 (UTC)[reply]

Proposal: Move software changelogs to a Fandom Wiki

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


There have been several cases in the past where the community has objected to large amounts of unencyclopedic content being hosted on Wikipedia. In each case, there has been a big fight and much gnashing of teeth. Ultimately, the most common solution to such problems has been to migrate the content to another wiki. This issue goes all the way back to the early days of Wikipedia in 2001 when we moved the September 11 memorials off of Wikipedia onto their own dedicated wiki. Similar cases have happened with popular media franchises like Pokemon and Star Wars which migrated to Wikia (now Fandom) wikis. A couple people in the discussions above have suggested doing this for the software changelogs, but no one has responded to these suggestions yet (that I've seen). What do people think of this idea? Nosferattus (talk) 12:17, 4 May 2023 (UTC)[reply]

I still think that Wikidata is enough to host software changelogs, but that also works. Miraheze would also be good. Aaron Liu (talk) 12:36, 4 May 2023 (UTC)[reply]
Wikidata requires the material to be free of copyright (either public domain or released under an appropriate CC license). Most change logs are copyrighted.
One can translocate an existing change log list from WP to another site as long as proper attribution is made, and that doesn't require a change in policy. Masem (t) 12:41, 4 May 2023 (UTC)[reply]
I don't personally agree. Fandom is far less popular than Wikipedia - while I disagree with some of Wikipedia's policies, it's still superior to platforms like Fandom and others - while I'm not bashing Fandom or anything, its not as robust as Wikipedia, and I see no reason why we should just ignore an entire article category over this specific policy. - Evelyn Marie (leave a message · contributions) 15:34, 4 May 2023 (UTC)[reply]
The persistent problem with those arguing in favour of keeping the changelog articles is one of popularity. If the information you want to be preserved is preserved then why does how many clicks the page gets matter? On Wikipedia, the changelog articles are going to be an ongoing source of disputes, moving them to a fandom wiki satisfies both sides. The information is preserved, but not on Wikipedia, and anyone who seeks it out won't have to go far to find it. TheInsatiableOne (talk) 15:51, 4 May 2023 (UTC)[reply]
The tables would be as useless there as here (seriously, they're quite bad); their only purpose is to provide a starting point for prosification. Would we move all stubs to another wiki, just because they suck? No, because keeping them here provides a good starting point for B-class, GA, class, and higher. Good version history articles should be written in high-level summary prose, but what's wrong with slapping {{table to prose}}, reverting edits that add to the tables and make the problem worse, and just letting the articles develop and get "fixed" over time? DFlhb (talk) 15:59, 4 May 2023 (UTC)[reply]
A lot of people don’t like wikidata for some reason and just use the tables Aaron Liu (talk) 16:01, 4 May 2023 (UTC)[reply]
I do think there's room to use tables in addition to prose, see for example iPhone OS 1#Version history, where tables are used to implement WP:PYRAMID, keeping encyclopedic-but-niche info at the bottom. Which also bolsters the argument that the current tables are a good rough starting point - DFlhb (talk) 16:14, 4 May 2023 (UTC)[reply]
The issue with the tables is falling into NOTCHANGELOG and INDISCRIMINATE. As well as being unencyclopedic. TheInsatiableOne (talk) 16:36, 4 May 2023 (UTC)[reply]
iPhone OS 1#Version history too? DFlhb (talk) 17:01, 4 May 2023 (UTC)[reply]
There are entries on those tables which say "minor update" at least twice. That very much falls into the aforementioned policies. TheInsatiableOne (talk) 17:18, 4 May 2023 (UTC)[reply]
No, the detailed bug fixes were replaced with Minor update to comply with those policies. Under WP:LISTCRIT we can't arbitrarily not mention certain versions, except for rapid-release web browsers where the number of versions is absurd. See WP:CSC point 3. — DFlhb (talk) 17:37, 4 May 2023 (UTC)[reply]
Thats just too much detail. The x.y releases can be highlighted, and noted parts of x.y.z updates can be mentioned, but the level of detail of x.y.z coverage is just what NOTCHANGELOG warns about. Masem (t) 20:18, 4 May 2023 (UTC)[reply]
iOS is an anomaly, as you had giants like Pogue and Mossberg penning whole articles on minor versions. I guess due to the excitement back then. Apple almost never released changelogs at the time, so most of this stuff was only covered by secondary sources, rather than only by primary sources. It might very well be excessive detail, but NOTCHANGELOG ironically doesn't help here. DFlhb (talk) 20:29, 4 May 2023 (UTC)[reply]
  • Comment - One additional thing: any list of commercial products/services, different versions of commercial products/services, updates to commercial products/services, has to pass WP:CORP. This goes for software as much as anything else. FOARP (talk) 10:44, 5 May 2023 (UTC)[reply]
Oppose external wikis only work if everything in them is interconnected of which changelogs are not, banishing a entire type of artical just becuase you dont like it isnt helpful in any way Popeter45 (talk) 14:42, 6 May 2023 (UTC)[reply]
Why would external wikis only work if everything in them is interconnected? It’s not just a matter of not liking it, it’s contrary to our goals as an encyclopedia. Aaron Liu (talk) 15:10, 6 May 2023 (UTC)[reply]
the thing that makes wikipedia useful is how articals link to each other so you can find tangental information on what your looking for, if there is zero links between pages will just lead to nobody being able to find them Popeter45 (talk) 22:32, 6 May 2023 (UTC)[reply]
So, in summary, nothing will link to the external wiki? Sure, but these articles are still getting deleted. Aaron Liu (talk) 02:44, 7 May 2023 (UTC)[reply]
On the basis of what, the current policy that says they should be kept to a reasonable length and cited to third-party sources? jp×g 23:49, 7 May 2023 (UTC)[reply]
This. Exactly! Huggums537 (talk) 21:58, 10 May 2023 (UTC)[reply]
The articles I cited were the ones that are noncompliant. Aaron Liu (talk) 22:56, 10 May 2023 (UTC)[reply]
  • Support - Just like plot summaries (which can also be sourced reliably) this stuff is ultimately just not encyclopaedia content, instead it is an exhaustive listing of updates to a commercial product and essentially advertising for it and/or stuff that the makers of that product should pay to cover themselves. FOARP (talk) 21:26, 6 May 2023 (UTC)[reply]
  • Support. There are already fandom wikis for most of these software, those seem like the ideal location for exhaustive changelog tables (which is what most of the redditors want anyway). JoelleJay (talk) 21:43, 6 May 2023 (UTC)[reply]
    By this do you mean the people who read Wikipedia, and whose readership is the sole purpose for which Wikipedia exists? I am no fan of reddit.com, but I think that the opinions of people who actually use our website matter substantially (perhaps more so than those of us who make a hobby of editing it). jp×g 23:49, 7 May 2023 (UTC)[reply]
    If we capitulate to readers, we'd go back to where we had full articles on each Pokemon and that type of nonsense. We are not the only source of information in the world, we are meant to summarize topics, not go into depth on them, so readers coming here to find that level of detail are in the wrong place. We should be able to provide them the resources to research further if they need more detail though. Masem (t) 00:14, 8 May 2023 (UTC)[reply]
    "Readers" also want exhaustive profiles of fictional characters and works, business directories, genealogies, breaking news, Ayurveda decoctions, etc. JoelleJay (talk) 02:36, 8 May 2023 (UTC)[reply]
  • Strongly oppose: we have an RfC a couple sections above that's split between leaving the wording as-is, clarifying it per the original consensus, and removing the section entirely. But here, the proposal is to make a new, additional section that goes far beyond the existing policy and newly forbids an entire broad category of articles on the basis of... what? It contravenes the consensus at deletion discussions, and the consensus which originally wrote this policy (which was explicitly in favor of these version history articles). As far as I'm concerned, it contravenes the basic principles of this project, i.e. to provide readers with verifiable, neutral information. The purpose of Wikipedia is not to showcase the literary skill of our editors, or to impress Britannica editor with the seriousness of the subjects we cover; it is to inform our readers. This is not something that goes against WP:V, WP:RS, and WP:NPOV; it's something that necessitates them. Verifiable content is better able to inform; reliably sourced content is better able to inform; neutrally written content is better able to inform. So the idea of arbitrarily saying that some broadly defined topic is "unencyclopedic" feels to me like watching somebody enter a chess tournament, play strong openings, play a strong midgame, play a strong endgame, defeat their opponents, and then insisting they are "bad at chess" because their shirt is wrinkled and they call the knight the "horsey guy". What does it mean to be "bad at chess" if you win? Why would it matter? Similarly, if something meets all of the actual criteria that we can come up with for being "encyclopedic", what basis is there to say that it's not? Note that the point I advance here is not novel; it's well precedented, and the original consensus on which this policy section was based goes along similar lines (per archive 45 of this very talk page). jp×g 23:49, 7 May 2023 (UTC)[reply]
    Detailed change logs goes against WP:NOT#IINFO - we are not a collection of indiscriminate information, even if that information mees V, OR, and NPOV. We are meant to summarize to a high level of what secondary sources say. Chess has a long huge written history and analysis of the game that our coverage can be a bit more detailed in gameplay aspects than recent tabletop game releases. Raw changelogs lack the secondary analysis to include them in full, though we recognize products like iOS can cover them to a level of major and minor changes through secondary sources. The raw changelogs are indiscriminate and beyond the scope of an encyclopedia. Masem (t) 02:46, 9 May 2023 (UTC)[reply]
    Calling the RfC "split" is definitely misrepresenting the consensus, especially since you spend the rest of your comment presenting a specific outcome of that RfC (removal of the policy) as the only previously existing consensus (which is verifiably wrong, as the existence of the policy itself shows). And this new proposal isn't, from what I understand, to forbid the (pretty narrow) category of changelogs - it is about what to do if they are forbidden. It entirely depends on the outcome of the previous one.
    Also, your chess analogy doesn't hold, and changelogs are far from "meeting all of the actual criteria" for being called "encyclopedic", as many editors have already explained above. In the same way as we don't have an article for every Pokémon, having an article for every single software update, regardless of their notability or analysis by secondary sources, is unencyclopedic. Chaotic Enby (talk) 15:21, 10 May 2023 (UTC)[reply]
  • Oppose [as premature because we don't even know what the outcome of the previous proposal is yet] and +1 agree with above statement vote 100%. I do love Wookiepedia, but let's not have another fandom Wiki just for software updates. Please, and thank you. Huggums537 (talk) 02:24, 9 May 2023 (UTC) Updated comment on 22:55, 10 May 2023 (UTC)[reply]
  • Comment: Some of us seem to be operating under the assumption that the changelogs won’t be removed from Wikipedia, while some are. In order for this proposal to progress we need to agree to assume one of these. Aaron Liu (talk) 12:58, 9 May 2023 (UTC)[reply]
    Assuming they won't, the decision for this proposal will already have been made, and so the only assumption relevant to this proposal is about what to do when (and if) the removal occurs. Huggums537 (talk) 05:58, 10 May 2023 (UTC)[reply]
    If so, it would make sense to preserve changelogs on an off-site wiki. Aaron Liu (talk) 11:39, 10 May 2023 (UTC)[reply]
    That's a fair point, but surely that isn't the sole option or solution available, and hopefully sanity would prevail where we would be prevented from ever reaching that fork in the road anyway. Huggums537 (talk) 14:04, 10 May 2023 (UTC)[reply]
Support There's the possibility of creating a wiki to host it on Miraheze, which is more robust than Fandom and also runs on MediaWiki. That would honestly be the best possibility. (Assuming that the previous RFC ends with the policy being kept and/or clarified, which is the most likely course of action currently) Chaotic Enby (talk) 15:16, 10 May 2023 (UTC)[reply]
Seems like you have made somewhat of a contradiction in terms here. If you are assuming the previous RFC ends in a consensus to keep and/or clarify, then what would be the point of this RFC if consensus has already decided to keep, and I *think* (not sure) the general rule is that a topic is not revisited again for six months? On the flip side of that, what would even be the point of having the previous RFC if one were allowed that could simply make it moot by just moving the changelogs elsewhere? Huggums537 (talk) 22:49, 10 May 2023 (UTC)[reply]
Wait ... what? The above RFC is related to keeping ... the policy that restricts changelogs; it's not related to keeping or deleting articles. It sounds like @Chaotic Enby is saying if the policy is kept/clarified, any noncompliant articles should be hosted off wiki. Unless I've totally lost the plot here?--Jerome Frank Disciple 22:51, 10 May 2023 (UTC)[reply]
What exactly is the point of having a policy for articles that would be hosted elsewhere? Huggums537 (talk) 23:38, 10 May 2023 (UTC)[reply]
Ah, I think I see. As I understood, the policy would describe the standard for Wikipedia articles; the articles that don't comply with that standard would be what was hosted elsewhere. But it sounds like you're interpreting Nosferattus's proposal as saying "put all pages with changelogs—regardless of whether they're acceptable according to WP:NOTCHANGELOG—on other wikis"--Jerome Frank Disciple 23:42, 10 May 2023 (UTC)[reply]
Well, that is another reason for me to oppose this as premature since not only do we have no idea what the outcome of the previous proposal is, but this one isn't really well defined either so you don't truly know what it is you are supporting or opposing. I don't even know why we are voting, or what exactly we are voting for. Huggums537 (talk) 00:03, 11 May 2023 (UTC)[reply]
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.

Update to NOTTVGUIDE

WP:NOTTVGUIDE states An article on a broadcaster should not list upcoming events, current promotions, current schedules, format clocks, etc., although mention of major events, promotions or historically significant program lists and schedules may be acceptable. I would recommend that we change this to An article on a broadcaster or program, to prevent edits such as this, listing a series' current or most recent season as a hatnote at the beginning of the article. -- Alex_21 TALK 20:56, 10 May 2023 (UTC)[reply]

There was a previous discussion on this exact matter (which you were involved in yourself) in November 2018. Given that you agreed that there was no consensus, I'm not quite sure why you're suddenly claiming that WP:NOTTVGUIDE is a, "direct policy against it". If you are that passionate about it, I would suggest opening a new discussion at WT:TV and attempt to get a consensus rather than directly attempting to change it just because you don't agree with it. Magitroopa (talk) 21:09, 10 May 2023 (UTC)[reply]
My apologies that I forgot about a discussion almost half a decade ago. Have I attempted to directly change the policy, can you show me any such diff? No, I open[ed] a new discussion at the relevant talk page. I'm not sure sure why the sudden hostility? What a very disappointing display from you. -- Alex_21 TALK 08:49, 11 May 2023 (UTC)[reply]
I'm not sure what hostility you read from that response...? It was moreso providing context/information, but if you read any sort of hostility from that, I do apologize. Anyways- the 'directly change the policy' I was referring to was actually regarding opening a discussion here rather than a new discussion WT:TV. Whether either of these talk pages are correct, it at least looks like your previous discussion at WT:TV didn't work the way you'd hope, so instead you came here to try and get a consensus to change it. Although I wasn't part of that original discussion, it feels like you're disregarding what was discussed then/there and are trying it with a different group of people. At least to me, it seems like it would be more appropriate to start a new discussion over there before coming here. Instead, it looks like you tacked the link to this discussion in an entirely different topic/discussion (yes, I understand the edit warring part is relevant to that discussion, but not the main gender topic being discussed there).
Yes, I'm sure editors from the previous discussion may have the same view point, but A) As you said, it was almost half a decade ago (2018 honestly doesn't feel that long ago, but I guess a pandemic can do something to your mind). Maybe some editors do have a different view point on it now. B) There are more editors (such as myself) who can/would like to comment their thoughts on this as well.
Honestly, the only way I had seen this discussion start was BrickMaster's edits (such as this) and then seeing the discussion regarding this topic at the bottom of that topic. I'm sure there might be some editors who wouldn't know about this because you added a link to this discussion in a discussion regarding American Idol articles/problems.
And finally, just going to say it again, I apologize for any hostility above (or in this message), but I really am not intending it.
TL;DR- Apologies for any hostility whatsoever, but seems like a discussion at WT:TV first regarding this would've been a better idea. Magitroopa (talk) 09:46, 11 May 2023 (UTC)[reply]
  • Um, why is that kind of hatnote a bad idea? People are likely to be most interested in the current season of a TV show, I find the hatnote a fine way to direct them there. I don't see why we want to prevent people from doing that at all. --Jayron32 13:37, 11 May 2023 (UTC)[reply]
  • I'm not sure NOTTVGUIDE is really the relevant issue here with the edit you're describing? The bigger issue is WP:HATNOTE, and whether that guideline means people should put hatnotes focused on recent seasons (I would say no, because hatnotes are not structured to link people to the most recent seasons of a show or similar, they're about clarifying confusion. If you end up on American Idol, the most important information to send to the reader is not "oh here's the latest season".) Der Wohltemperierte Fuchs talk 17:08, 11 May 2023 (UTC)[reply]
But it does clarify confusion. Most people are interested in a TV show because it is showing on television, they may be interested in the general article, or the current season. It would tell people who are interested on the current season where to go, without them having to hunt for the current season out of many other seasons. Hzh (talk) 19:27, 11 May 2023 (UTC)[reply]
If the hatnotes are kept, maybe there can be further discussion about when/where to use it for this purpose. Just as an example... I don't think a 'current season' hatnote would be that necessarily for The Mandalorian, which currently only has three seasons. On the other hand, it would likely be appropriate for articles like American Idol with 21 seasons/articles or The Simpsons with 34 seasons/articles. Magitroopa (talk) 22:30, 11 May 2023 (UTC)[reply]

Why would there be a problem with this hatnote? The only objection I can think of is that it says "current", which is a little annoying (i.e. WP:CURRENT). jp×g 20:49, 11 May 2023 (UTC)[reply]

RFC on WP:NOTCHANGELOG clarification


It is clear that the vast majority of editors want to see the policy stay; however how about clarification? This policy does not, within its current meaning, say that articles bound by the policy, e.g. version history articles, are outright banned. It says to use common sense on the amount of detail to include, and only states exaustiveness, e.g. listing comprehensive release notes for every little change, but major feature highlights and version summarizations (e.g. as seen on Fedora Linux release history and Ubuntu version history) should not run afoul of this. So, instead of removing the policy outright (which after having thought about it is indeed a bad idea as it could result in more copyvio happening), how about clarifying the policy to allow highlights of major features and version summarizations directly, while disallowing comprehensive detail such as change-by-change release notes? The previous RFC specifically focused on removal, and clarification wasn't really discussed, so it might be better to have a second RFC. This is what I personally had in mind:

Current wording

Exhaustive logs of software updates Use reliable third-party (not self-published or official) sources in articles dealing with software updates to describe the versions listed or discussed in the article. Common sense must be applied regarding the level of detail to include.

Suggested

Exhaustive logs of software updates. Use reliable third-party (not self-published or official) sources in articles dealing with software updates to describe the versions listed or discussed in the article. Common sense must be applied regarding the level of detail to include; e.g. comprehensive release notes of individual software versions should be excluded, while major feature highlights and version summarizations should follow the policy on reliable third-party sourcing.

With changes of course to perhaps improve wording and remove unnecessary word duplication. But the policy in its current state is open to vast misinterpretation, and has been misinterpreted to turn exhaustiveness into saying that version history articles are straight up not allowed. So I am seeking opinions and debate on whether or not this policy should be clarified. - Evelyn Marie (leave a message · contributions) 10:16, 15 May 2023 (UTC)[reply]

I am withdrawing this proposal - its clear that there is not going to be a consensus. I'd much rather WP:CHANGELOG just stay at its current wording at this point. - Evelyn Marie (leave a message · contributions) 16:57, 17 May 2023 (UTC)[reply]

  • Comment - To add on, there is no reason to assume that version history articles can't be enyclopedic or notable, even if tables are used for example. Tables aren't bad, if they were they wouldn't be supported on Wikipedia to begin with. I do agree that editors have found it okay to include change-by-change release notes, especially on certain OS-related version history articles, however if they can be condensed down to only have highlights or version summaries instead of entire release notes with signfiicant, reliable, and third-party sourcing, wouldn't that be okay? - Evelyn Marie (leave a message · contributions) 10:16, 15 May 2023 (UTC)[reply]
    Tables of change logs tend to end up as tables with bullet-point lists within some cells that give the effective appearance of a changelog, particularly when it is written in the same tech-speak language most changelogs are written in. Its why we do want summaries of key features, writing more in a prose form, though can still be organized in a table to identify version numbers and release dates. Masem (t) 12:39, 17 May 2023 (UTC)[reply]
  • (Summoned by bot) Ubuntu version history is (imho) exactly what we should have on Wikipedia (well, the sourcing could be improved to rely less heavily on primary sources, but besides that; we do not require WP:PERFECTion). Your proposed wording captures this well, so support. On a related note, I don't think tables are inherently bad, but I do think we have a problem if tables make up almost the entire article. HouseBlastertalk 11:55, 15 May 2023 (UTC)[reply]
  • I'm okay with the above proposed clarifications, but article organization and content is properly an MOS issue, and not one for WP:NOT. --Jayron32 12:44, 15 May 2023 (UTC)[reply]
  • Comment: I don't know that a formal RfC is strictly necessary for the specific wording of text that's just a rewording of existing consensus. I mostly like this, although it is not verbatim what I would write if I were to go do it myself. I think some prominence should be given to some of the specific items agreed on at the original discussion in Archive 45, as well as the broader point that the policy was explicitly amended so as to permit version history articles (and indeed tables) so long as they summarized significant modifications rather than listing every patch note in full detail (to wit: "effectively ban changelogs for minor software packages, but allow significant changes in more notable software to be included"). jp×g 13:48, 15 May 2023 (UTC)[reply]
    @JoelleJay, who reverted my edits on WP:NOT despite Archive 45, seems to think otherwise. When I brought it up on their talk page, they said the consensus doesn't matter, even though the prev. RFC was strictly only dealing with removal of the policy, which I backtracked on. As I stated in this RFC removal of the policy shouldn't take place after all. - Evelyn Marie (leave a message · contributions) 14:05, 15 May 2023 (UTC)[reply]
    You cannot just change policy to reflect your interpretation of the results of a 9-year-old discussion among like 8 editors, on a currently heavily contested topic, and expect those changes to be retained. As I said in the revert, adding in examples of what details are exempted from NOTCHANGELOG is a major deviation from the current wording and should achieve consensus. The last clause is also still nonsensical (what policy on third-party sourcing?). JoelleJay (talk) 22:23, 15 May 2023 (UTC)[reply]
    The policy that every Wikipedia article is expected to and required to follow - WP:RS. What other policy could it possibly imply? - Evelyn Marie (leave a message · contributions) 22:39, 15 May 2023 (UTC)[reply]
    • WP:RS is not a policy, and it does not contain any relevant language on third-party sourcing, so that clause makes no sense.
    • Of course the age of a discussion matters. An informal proposal with 8 participants that fizzled out without closure 9 years ago is not a reflection of current consensus. Additionally: Bold editors of policy and guideline pages are strongly encouraged to follow WP:1RR or WP:0RR standards. Editing a policy to support your own argument in an active discussion may be seen as gaming the system
    JoelleJay (talk) 23:14, 15 May 2023 (UTC)[reply]
    You're joking right? WP:RS literally opens up with the following:

    Wikipedia articles should be based on reliable, published sources, making sure that all majority and significant minority views that have appeared in those sources are covered (see Wikipedia:Neutral point of view). If no reliable sources can be found on a topic, Wikipedia should not have an article on it.

    This literally is effective policy. No articles on Wikipedia should exist without reliable sourcing...but if you want to get technical, proper sourcing policies to follow would be WP:V, and WP:PRIMARY, but WP:RS is still effective policy as both of these policies mention it. I'd love to know how you're coming up with these arguments because they aren't exactly valid... - Evelyn Marie (leave a message · contributions) 23:21, 15 May 2023 (UTC)[reply]
    Please review WP:POLICIES to understand what a policy is. Guidelines != policies. WP:RS: This page documents an English Wikipedia content guideline.
    What you quote from WP:RS says nothing about third-party/independent sourcing. WP:V references independent sources in its "notability" section, but does not provide instruction on what they are or whether/how they can be used for non-notability purposes; WP:PRIMARY discusses primary/secondary sources and mentions that these may or may not be independent, but does not otherwise describe what this means. Therefore, neither of these can be the "policy" we are supposed to follow for NOTCHANGELOG, which applies a third-party restriction to specific content irrespective of notability. If you are just trying to reference the definition of "third-party", well, there's a reason it is not already wiki-linked in NOTCHANGELOG and why the parenthetical there exists. JoelleJay (talk) 01:28, 17 May 2023 (UTC)[reply]
  • Oppose any rephrasing including "common sense". It is clear from the massive RFC above that the common sense test does not work in this situation. The inclusion of the phrase 'common sense' in the existing policy is a problem because people clearly disagree on what is common sense. We need a wording that is more explicit and instructive. It should, at a minimum, define what an 'exhaustive log of software updates' is, provide a remedy, and then talk about sourcing. WP:NOT is definitional to the encyclopedia. It should include definitions. Sourcing instructions are secondary to that. Axem Titanium (talk) 15:32, 15 May 2023 (UTC)[reply]
    @Axem Titanium: Hmm. I understand where you're coming from. I don't like the common sense wording either - everyone has a different definition for what is "common sense", same as to how everyone could have different opinions on what "exhaustive" means. I am not the best at phrasing, but I guess I could take a crack at it. In my eyes, an exhaustive log of software updates would be a very comprehensive listing of versions that include very technical details that most readers do not care about (e.g. build numbers and code names, unless a code name is part of that version's marketing - this is very common with Ubuntu releases, e.g. Ubuntu 23.04 Lunar Lobster), and extensive release notes detailing every single change made to an individual software version, e.g. iOS 16.4.1. Extensive release notes on version history articles should be avoided due to the potential risk of copyright violations, especially if release notes aren't made available on a permissive basis, and the fact that they aren't very encyclopedic. Comprehensive and extensive are terms that have pretty solid meanings, and they're typically understood by most people to mean "complete". Below is what I think could be used instead, if the example I gave isn't that great (tweaks, fixes, and improvements to wording welcome because I am not an expert in English, lol):

    Exhaustive logs of software updates. An exhaustive log of software updates is a log of software updates that includes intricate details that most readers are not interested in, such as a build number or code name (unless used to refer to that software version publicly), and comprehensive release notes covering every change to an individual software version in extensive detail. Information that matches this criteria should be excluded, while highlights of major features and version summaries should use reliable, third-party sources.

    I am by far not the best at phrasing things, but this is my initial take on what the policy could look like with your opinion taken into consideration. It's probably not very good, but it would be a start I think. - Evelyn Marie (leave a message · contributions) 16:40, 15 May 2023 (UTC)[reply]
@Axem Titanium: This is a good point; I don't like the "common sense" thing much either. Hopefully it can be avoided. jp×g 16:43, 15 May 2023 (UTC)[reply]
  • 100% agree with Jayron & HouseBlaster, and won't repeat their points. Axem Titanium is right that we should focus on defining "exhaustive". DFlhb (talk) 23:19, 15 May 2023 (UTC)[reply]
  • Oppose rephrasing - The premise on which this amendment is being proposed is that changelogs are permitted, however there is no consensus to this effect, quite the opposite in fact. FOARP (talk) 15:11, 16 May 2023 (UTC)[reply]
    Indeed, there is a consensus that changelogs should not happen, but there are still two matters: 1) disagreement over what kinds of content counts as a "changelog", and 2) Disagreement over how to handle changelogs (improve the article or delete it). None of these represents any disagreement over the PAG itself. --Jayron32 15:29, 16 May 2023 (UTC)[reply]
There is no lack of clarity over what failure of WP:NOT results in - it is WP:DELREASON #14.The above proposal appears to be an attempt to define a carve-out wherein change-logs could still be maintained, as is indicated by the references to change-log articles that should be "OK". For the avoidance of doubt, yes this is a changelog. FOARP (talk) 15:52, 16 May 2023 (UTC)[reply]
Not necessarily. Lots of what is written at the WP:NOT page is guidance on how to write articles, not on deletion. Some violations of WP:NOT may merit deletion, but some may just merit some cleanup. Deletion reasons are not mandatory. We don't have to delete every single article that contains some possible violation of something written in WP:NOT. Sometimes, the problems can be fixed by normal editing. --Jayron32 15:58, 16 May 2023 (UTC)[reply]
Not if the article is literally "Version history of XXXX", in that case what you have is a change log. "History of XXXX" would be a different story, but also a very different article. FOARP (talk) 16:05, 16 May 2023 (UTC)[reply]
Very much not true, @FOARP - Look at articles like Ubuntu version history. Your argument doesn't hold that much valid ground. - Evelyn Marie (leave a message · contributions) 17:08, 16 May 2023 (UTC)[reply]
Also it should be noted that you are arguing with an administrator. - Evelyn Marie (leave a message · contributions) 17:09, 16 May 2023 (UTC)[reply]
Adminship on Wikipedia is WP:NOBIGDEAL, Evelyn. I respect Jayron the same way I respect all editors on here, no more, no less. FOARP (talk) 18:38, 16 May 2023 (UTC)[reply]
Back down, Evelyn. I may be an admin, but my comments here hold no more weight than do FOARP's. We disagree, but I don't "win" because I have access to a few more editing tools than they do. Arguments are judged on their merits, not on who makes them. --Jayron32 11:11, 17 May 2023 (UTC)[reply]
No, it is not a changelog. A changelog is a complete, entire list of changes to a given software version. Feature highlights alone do not count towards this, therefore your supposed claim is null and void. - Evelyn Marie (leave a message · contributions) 17:15, 16 May 2023 (UTC)[reply]
@FOARP: I don't think this is true. The discussion in R45, which is as far as I can tell the totality of this policy's basis, reached unanimous consensus that version history articles should be protected. That's literally the reason that the policy was written at the time. Here is the first item of the proposal: "Require changelog items to have reliable third-party sources. This will still effectively ban changelogs for minor software packages, but allow significant changes in more notable software to be included". Has there been some subsequent consensus to expand it to "all version history articles should be deleted"? There have certainly been people claiming at AfD that it does say this, but I have not seen anyone argue that it should say this. jp×g 22:04, 16 May 2023 (UTC)[reply]
That literally is not what I'm proposing?! I'm proposing rewording to allow "X version history" articles to exist, if they aren't sorely focused on changelogs, and even then, if changelogs weren't allowed, whats the point of even having exhaustive? Your opposition to this makes zero sense to me. - Evelyn Marie (leave a message · contributions) 17:11, 16 May 2023 (UTC)[reply]
Also, I'm proposing the wording be changed to disallow exhaustive and complete release notes, but allow bullet point feature highlights and version summaries, e.g. like in Ubuntu version history (which I wikilinked above). Articles like those do NOT count towards a changelog. - Evelyn Marie (leave a message · contributions) 17:21, 16 May 2023 (UTC)[reply]
  • Comment: I would suggest those changelogs in firefox version history and iOS version history be split into individual articles, instead of having them deleted by user:evelyn Marie. Take a look at windows 10 version history for example, which got previously nominated for deletion in 2018, unsupported versions were split to their own articles. Only supported builds are currently being displayed in the main page. If we have those updates displaying in windows 10 version history and windows 11 version history, then Y can't other similar pages have the same? Such consensus should have been reached in other pages as well, including the recently deleted Google Chrome version history.197.244.87.87 (talk)
    I removed the tables due to the comprehensive detail they had and the fact that they were barely sourced, but I do intend on bringing them back once I figure out how to best add them back, but splitting them off is a bad idea - I strongly oppose that. and not to mention, this is the wrong place to show your support for that. - Evelyn Marie (leave a message · contributions) 17:37, 16 May 2023 (UTC)[reply]
  • Comment - Just a reminder that any article that is solely dedicated to a product/service provided by an organisation (commercial or not, regardless of whether it is for-profit or not) has to pass WP:NCORP, particularly WP:AUD. The idea some people seem to have here that you can produce an article that is manifestly entirely dedicated to a product/service based solely on highly specialist media of dubious reliability, and the website of the organisation that produces that product/service, is frankly for the birds. FOARP (talk) 08:55, 17 May 2023 (UTC)[reply]
    Not true. That’s strictly a guideline, not a policy - check the banner at the top, FOARP. Guidelines can’t be enforced. - Evelyn Marie (leave a message · contributions) 09:17, 17 May 2023 (UTC)[reply]
Evelyn Marie, try creating putting an article about a piece of software produced by a company based on a specialist webzine and the company's own website through articles for creation and let me know how the whole "WP:CORP is not enforceable" thing goes. FOARP (talk) 09:27, 17 May 2023 (UTC)[reply]
not as strongly enforced* if it was a straight up strict policy then yeah it would severely matter but whether or not a news source focuses on a given company doesn’t make it any less reliable if it’s still editorially independent. it would be different if it was sponsored by a company, but most companies don’t sponsor independent publications. but anyways unless it’s converted to a policy you can’t reasonably enforce it, it would kill a severe amount of news sources that people use for articles despite them still being editorially independent and reliable. - Evelyn Marie (leave a message · contributions) 09:24, 17 May 2023 (UTC)[reply]
Guidelines are not "policies you can ignore" and policies are not "guidelines that must be followed at all costs". Policies and guidelines serve different purposes, and both should be followed unless you're prepared to defend a specific edit or action that runs counter to them. --Jayron32 11:09, 17 May 2023 (UTC)[reply]
Indeed, and if the intent here is to amend/disapply WP:CORP (especially WP:AUD and WP:ORGIND) that has to be defended on its own merits. It has been repeatedly asserted that all that is needed is specialist press coverage, but coverage beyond that is needed for these articles to be included under WP:CORP. There is no obvious reason to distinguish between articles about updates to a piece of software and, say, articles about updates to the Big Mac, the Porsche 911, or New Coke: these are all products/services produced by organisations for consumption by others. FOARP (talk) 11:20, 17 May 2023 (UTC)[reply]
  • A lot of strongly-held views are just being restated, which can't plausibly move us towards a resolution. Not trying to play "discussion police", but before posting, please consider whether a comment is intended to achieve a concrete change in this policy, or just turning battle-lines into deep trenches. DFlhb (talk) 09:37, 17 May 2023 (UTC)[reply]

Counterproposal to RFC on WP:NOTCHANGELOG clarification

Add A list of every version/beta/patch is inappropriate. Consider a summary of development instead. to NOTCHANGELOG, taken from the WP:GAMECRUFT guideline.

  • Support as proposer. We should learn from WikiProject Video games. They had the same changelogs, debated them, and removed them, without the need for community intervention (see how it used to be: [9][10][11][12][13][14], now all turned into prose). It appears that they tried the "keep and let others improve" approach and it didn't work out, so they removed the tables (not AfD, still in the revision history). That was apparently the only effective solution to finally get people to write good prose and avoid cruft.
Side note: I think we would never have ended up here if WP:COMPUTING has a MOS guideline like MOS:VG. Let's draft one. DFlhb (talk) 14:01, 17 May 2023 (UTC)[reply]
  • Oppose - This would kill the existence of iOS version history, and would outright ban articles like Ubuntu version history from existing at all - what i mean is your wording runs opposite of each other, saying "avoid a list of every version" while saying "consider a summary of development instead" runs directly contradictory to that first part. So no. I find this proposal to be outright nonsensical. There wouldn't have even been an issue here if people didn't straight up copy/paste release notes for major versions into the tables to begin with - there is nothing wrong with having a detailed listing of versions and their release dates along with feature highlights if they are reliably sourced - iOS especially gets an absolute insane amount of coverage, thereby making even minor iOS releases notable. So I'm sorry but I honestly severely oppose this. - Evelyn Marie (leave a message · contributions) 14:44, 17 May 2023 (UTC)[reply]
Additionally I am going to quote what MASEM said above to here - even they agree that tables are ok if they aren't super comprehensive in terms of change-by-change detail, at least from what I'm gathering:

Tables of change logs tend to end up as tables with bullet-point lists within some cells that give the effective appearance of a changelog, particularly when it is written in the same tech-speak language most changelogs are written in. Its why we do want summaries of key features, writing more in a prose form, though can still be organized in a table to identify version numbers and release dates. - MASEM

That is what they said. If we avoid tech-speak, and write strictly in prose even in the tables while avoiding detail on severely minor things like bug fixes and every single security fix under the sun, wouldn't that no longer violate WP:CHANGELOG and avoid the need for this proposal altogether? The only reason I can gather as to why the tables were removed from the system software articles were because system software for consoles never received a significant amount of coverage, especially when majority of them were severely minor in scope with only performance improvements, so the ability to write prose in the tables wasn't really possible, however in iOS' case specifically, like I mentioned, it receives an insane amount of news coverage, even for minor updates. As an example, even The Indian Times covered the 16.4.1 Rapid Security Response, and that is like the most minor of minor updates where it only had like one security fix. So obviously the security responses alone would be excluded from the tables. But side note, even now the system software articles are still not that well written. Back on topic though, I genuinely do not believe that tables are a sin to the point of outright banning (especially when something is notable enough it should be covered on Wikipedia, which again, iOS updates are typically covered in-depth by a billion news outlets), and so I severely dislike this proposal in general. Exhaustive release notes should be avoided, I agree. But tables are the best way to detail iOS releases. I genuinely do not understand how, since the iOS version history article's creation back in 2008-2009, the article is now now all of a sudden getting so much controversy by a minor group of editors despite the broad consensus that the tables were fine. Archive 45, the basis of which the current revision of the change log policy was even based on to begin with, was based on the idea that tables should be allowed, but should not be extremely in-depth as to the amount of detail.
I do agree that the iOS version history article, for the longest time, went above and beyond of what it should've been in terms of detail, but the tables themselves were not the reason why. The obscene amount of detail in the changes column combined with the fact that people had a tendency to pretty much rip off Apple's release notes was the main factor. However, if we can avoid that, I see no reason why for that article specifically we can't avoid breaking WP:CHANGELOG. Feature highlights and sentences that briefly detail the changes made to an iOS update do not violate this. - Evelyn Marie (leave a message · contributions) 15:07, 17 May 2023 (UTC)[reply]
  • Support - Essentially what we should be aiming for is a summary-level explanation of the history of the product, assuming that the product's history is notable per WP:CORP. That's what encyclopaedias do: they summarise. They do not list exhaustively. There is no reason why software should be treated any different to any other product/service in this regard. Would anyone believe that a complete listing of all the updates to the Happy Meal was appropriate (and yes, sourcing exists: 1 2 3)? Every different toy included and every different ingredient-change explained? No? So why do the equivalent of that for software? If the argument is "but software is important/useful" that's an old fallacy hereabouts and anyway my kids would definitely argue the importance of the Happy Meal.
Arguments predicated on this or that previously existing article need to look hard at WP:OTHERSTUFF. There is no reason why any of the existing change-log articles need to be kept in their present form.
DFlhb's proposal is a sane one that should be given serious consideration. That computer games are close to (I would say identical with actually, since they are both ultimately software) the topics under discussion is patently obvious now that they have mentioned it. Why, indeed, should we have a version history of World of Warcraft, or Eve Online, or Fortnite, rather than just summarising their history? And if not these then why Firefox which is ultimately just a browser? FOARP (talk) 15:35, 17 May 2023 (UTC)[reply]
....Except software like iOS constantly evolves through minor software versions, e.g. 16.1, 16.3, etc. There is no easy way to summarize that, which is why tables exist - tables allow summarizing without having a billion paragraphs of prose on each individual software version in a version history article. Video games barely get major updates, except for live-service games, but the vast majority of games are completed before they even ship. Software like mobile operating systems are vastly different in that they continuously get updated on a monthly basis, in the case of iOS. Tables are severely useful to summarize the changes of software versions, and they cannot be adequately summarized in prose. So no. I disagree. - Evelyn Marie (leave a message · contributions) 15:48, 17 May 2023 (UTC)[reply]
Maybe the prose doesn't need to cover it at that exhaustive level of detail either. --Jayron32 15:55, 17 May 2023 (UTC)[reply]
@Jayron32 Except it should because like I've said a billion times now - iOS as a piece of software is severely notable, so notable to the point of receiving significant coverage on even Rapid Security Responses. This line of thinking is in my opinion disrespectful to iOS' importance as a piece of software that billions of people rely on to live their lives. Maybe you might not think detail like that is important, but you're only one person out of the 8+ billion people that exist on this planet, or the hundreds of millions of people who read Wikipedia on a daily basis. Making the content Wikipedia can contain more restrictive, despite the fact that iOS versions (including minor ones) receive significant coverage, and in the iOS version history article's case specifically, it is one that has received significant page views and so is clearly important, is counter to the reason why Wikipedia is so popular, and why the iOS version history article is so popular to begin with as well - people have found immense value in the tables and have said so as such on its talk page as well. While having immense detail in them runs counter to Wikipedia's summarizing goal, maybe that shouldn't be the only thing Wikipedia focuses on? Not everything needs to be summarized, nor should it be. If it was, as an example we could summarize WWII to only say "WWII was a global war that happened from 1939 to 1945, and resulted in tens of millions of casualties." and leave it at that, leaving the page significantly empty. But no. A significant amount of detail to adequately cover that subject is required, and the same applies to iOS as a mere example.
On another note, these policies are ancient, presumably do not reflect what people use Wikipedia for, and we should consider that people use Wikipedia as something other than merely an encyclopedia in 2023. And a small minority of the total group of editors on Wikipedia is not how consensus should be formed either. Most editors never even find out about these discussions, and so do not participate in them. A view that might be shared by one group of editors might not reflect that of another group of editors who don't even know that discussions like these exist, and could be bigger than the other group, which is why this whole process is kinda whack to me. - Evelyn Marie (leave a message · contributions) 16:10, 17 May 2023 (UTC)[reply]
Saying it a billion times doesn't make it more right than saying it once. I'm not saying the world <waves hand vaguely at the world> doesn't need the information. It's just that Wikipedia is not the correct place to house it. We're an encyclopedia, consisting of articles that summarize important topics. Let someone else document this information at that level of detail. Wikipedia doesn't need to. --Jayron32 16:19, 17 May 2023 (UTC)[reply]
@Jayron32 so then list-class articles should just not exist at all either then? If you feel the need to bring up the whole summarizing thing so strongly, then maybe list-class articles shouldn't exist on Wikipedia either and should be outright banned too. That is precisely why I think this entire counter proposal is so whack. If one thing gets banned, that will lead to more things getting banned and/or restricted, and then Wikipedia as a whole will become significantly less useful, which is not what Wikipedia should be aiming for. - Evelyn Marie (leave a message · contributions) 16:26, 17 May 2023 (UTC)[reply]
I never said that. You're the first person to say that right now. Please don't put words in my mouth I did not say. --Jayron32 16:32, 17 May 2023 (UTC)[reply]
@Jayron32 I didn't say you said that either. I gave an example. Wikipedia is a significantly important part of the Internet. Recording major features added in versions of software like iOS is historical especially when something like iOS is used by billions of people, and it is significantly notable, and therefore belongs on Wikipedia. Maybe Firefox doesn't deserve its own version history article due to the fact that Firefox doesn't get significantly new features like iOS does and therefore receives nowhere near as much coverage on its individual software releases, but iOS gets so much coverage its kinda hard to keep track of. I'm specifically trying to argue for iOS version history here purely based on its significant notability, even for minor versions. That is specifically why I disagree with this whole proposal, because it has a chance of killing off valuable articles that definitely have a place on Wikipedia, especially when it comes to notability. - Evelyn Marie (leave a message · contributions) 16:41, 17 May 2023 (UTC)[reply]
You've said so more than once, a "billion times" by your own estimation, which is more than is necessary. Repeating yourself doesn't add more weight to your argument. All it does is overwhelm the discussion and discourage additional voices from being heard. I've made my feelings known below, and I've said enough at this point. I suggest that you probably also have. Let others get a word in; you don't need to repeat yourself every time someone has a different perspective than you do. Your feelings are already well documented. --Jayron32 16:49, 17 May 2023 (UTC)[reply]
@Jayron32 I have withdrawn my proposal and RFC, and with that, I am done. I'm tired of being criticized and linked to the same thing over and over again for merely stating my opinion. The only thing I ever tried to do was try and point out the facts. There is valid usefulness to having detail of software releases on Wikipedia if there is significant notability (because Wikipedia is significantly more important than Fandom which is not properly moderated at all) but its clear that due to the fact that the vast majority of people never discover these discussions, it will always be the exact same group of editors voting to either "keep", "delete" and "support" or "oppose" over and over again with no fresh perspectives ever being given. Until these processes change I am done partaking in conversations like these because it is clear that it is severely biased towards very small groups of editors that are impossible to gauge the consensus for, when the same group of editors seem to comment over and over again. - Evelyn Marie (leave a message · contributions) 17:06, 17 May 2023 (UTC)[reply]
There you are again, claiming things about me that I didn't do. I've been involved in these conversations for a week or two at most, and I've not disagreed with you over most issues; indeed above I expressed support for your proposal. I've barely interacted with you for more than a few days. Your accusations against me are growing wearisome. --Jayron32 17:21, 17 May 2023 (UTC)[reply]
@Jayron32 I'm not talking about you, I'm talking about in general about the numerous times I've been linked to that same policy by numerous editors when I've only tried to state my opinion. Hell, I was even linked to that policy after replying once on an RFD. I apologize for making it seem as if I was talking about you, I wasn't. I was trying to show my ire at the amount of times in general that I've been linked to that policy. And I should note that I was additionally not including you in the "group of editors" - you're perfectly fine, i don't have any issues with you, however I do have issues with editors who find it necessary to comment on every AfD, instead of letting others make their voice heard. - Evelyn Marie (leave a message · contributions) 17:26, 17 May 2023 (UTC)[reply]
Also Firefox is not "just a browser" - it is a significant piece of software that millions of users rely on to do every day tasks on a computer - it is a fundamentally important piece of software. Arguably more fundamentally important than video games, which while fun, are not fundamental pieces of software that allow users to do everyday tasks. - Evelyn Marie (leave a message · contributions) 15:54, 17 May 2023 (UTC)[reply]
@FOARP, making an OTHERSTUFF argument against other users while pointing at otherstuff they do over at NCORP and while praising DFlhb for a proposal completely based on otherstuff they do at GAMECRUFT has to be one of the most hilarious things I've had the pleasure to witness today. Thanks. Huggums537 (talk) 01:39, 18 May 2023 (UTC)[reply]
Hi Huggums, I get the irony. In my defence, the distinction I’m trying to highlight is between “this thing is in the same class as these other things and the same policies should apply” and “this thing exists so this other thing should exist, regardless of policy”. FOARP (talk) 05:01, 18 May 2023 (UTC)[reply]
Yes. Not only did I not advocate for the latter, it's an unimpressive interpretation of WP:OTHERSTUFF. OTHERSTUFF is Fallacy of relative privation. My argument isn't comparative, it's on the merits. DFlhb (talk) 05:15, 18 May 2023 (UTC)[reply]
I think the former is the "unimpressive interpretation" of an OTHERSTUFF argument denial. If your argument was based on merits of policy alone, and not comparative, you wouldn't have been saying we should "learn" what they are doing over at GAMECRUFT manual of style (a video game manual not meant for all our articles) and take it to use in our policy. Huggums537 (talk) 10:07, 18 May 2023 (UTC) Updated comment on 10:32, 18 May 2023 (UTC)[reply]
To put it more simply, I think it absolutely is an OTHERSTUFF argument to say that the video game fanboys are using this stuff in their manual so we should put it in our policy. It isn't meant to be an interpretation to impress anyone, but to be very easy to understand. Huggums537 (talk) 10:49, 18 May 2023 (UTC)[reply]
  • Support Rewriting these articles as prose seems like good advice. --Jayron32 15:38, 17 May 2023 (UTC)[reply]
    @Jayron32 Except it's not - see what I said above. - Evelyn Marie (leave a message · contributions) 15:49, 17 May 2023 (UTC)[reply]
    I saw what you said above. I just don't agree with it. --Jayron32 15:49, 17 May 2023 (UTC)[reply]
    No, not that Jayron. The reply I made to FOARP. - Evelyn Marie (leave a message · contributions) 15:51, 17 May 2023 (UTC)[reply]
    I read that too. I just don't agree with it. --Jayron32 15:54, 17 May 2023 (UTC)[reply]
    Evelyn Marie - I'm not an admin, I'm just an average Joe Bloggs on these here boards, so you don't have to listen to what I say if you don't want to, but seriously give WP:BLUDGEON a read and a think, and consider whether it is necessary to respond with what from my (no doubt biased) POV appear to be similar talking points to every comment that you disagree with. Again, I'm just a lowly editor, but when you've edited this page nearly 80 times this month already, meaning that on a page with dozens of contributors you made roughly 1/6th of the edits, could it just be possible that you may be "attempt[ing] to force [your] point of view by the sheer volume of comments [...] contradicting every viewpoint that is different from [your] own .. making the same argument over and over, to different people" and that may not be the best way of getting your point across? FOARP (talk) 16:33, 17 May 2023 (UTC)[reply]
    The vast majority of those edits were me fixing typos and other mistakes I made - I do that a lot, if you see my contribution history in general for all articles I've ever contributed to. I'm not trying to force my opinion on anyone but I am allowed to state it. - Evelyn Marie (leave a message · contributions) 16:36, 17 May 2023 (UTC)[reply]
  • Support. Having this explicitly documented would resolve a lot of issues related to these pages. JoelleJay (talk) 00:04, 18 May 2023 (UTC)[reply]
  • Oppose; this seems to me quite a bit worse than the current wording. As Evelyn Marie said, it sounds like it would just put the torch to a bunch of articles that have nothing else wrong with them. The way I see it is this: a bunch of people want these articles to go away, and the only reason I have heard is that they interpret this policy to say that. I have not heard any reason why it should say that, and I don't see one here either. To explain what I mean: I believe that policy forbids articles like "List of reasons why Barack Obama is a dick", and also that we shouldn't have them. If it somehow turned out that policy said nothing about this and WP:BLP was a redlink, I might say "Wikipedia is not a repository for polemics about why politicians are dicks", but I would also have an answer for "well, why shouldn't it be". I could still articulate a number of arguments as to what principles suggested we shouldn't have it: it's not written objectively, it's impossible for it to be written objectively, it's impossible for it to be neutrally and reliably sourced, it hampers Wikipedia's mission of providing helpful knowledge, it poses legal issues for the project, it poses political issues for the project, it establishes an untenable precedent that people are allowed to go off on political rants in mainspace, and so on and so on. Here, I do not see a reason for why something like IOS version history is bad, other than "the policy says so": if it doesn't, then it's not, yes? jp×g 03:18, 18 May 2023 (UTC)[reply]
    There’s a number of reasons why an exhaustive version history of iOS should be outside the scope of this project. Here’s some of them:
    1) iOS is a software product that competes on the market against other software products. A complete version history is effectively advertising for it and/or something that the organisations that create it/profit from it should pay for and maintain themselves. This applies equally to open source software like Android, since they are still software products competing on the market and which organisations profit from.
    2) Excepting iOS from a general bar on advertising for and exhaustive description of products that compete on the market against other products is not something that is going to stand. It would not be neutral between commercial products and involve us taking sides, so in the end others would be allowed too. We would end up with complete version/feature histories of all products - cars, planes, software, foodstuffs, etc. - that sourcing could be provided for, turning Wikipedia from being an encyclopaedia to being a free general-purpose repository for data about commercial products.
    3) Such data is not of interest to our audience, who are the general-interest crowd, not specialists. Indeed, it leads to a wall-of-text that puts them off.
    Now you might disagree with the above, and the other arguments on this that have been made by others, but you cannot say that no-one has been able to express any reason why we should bar this kind of content. FOARP (talk) 06:34, 18 May 2023 (UTC)[reply]
The existing policy already says in gigantic bold letters that exhaustive lists of every change between versions of software are not permitted, so if this is the thing you're opposed to, we are already in agreement with both each other and the policy, and there is no need to add more stuff to make it more strict. As for points 2 and 3, I would enjoy responding to them but I think first we should see if we do not already have similar opinions here. jp×g 08:47, 18 May 2023 (UTC)[reply]
The issue is it appears that the gigantic bold letters are not clear enough. This clarifies that what should be done is a summary of the history of the development of the product - a far more human approach leading to a more reasonable and readable structure. Contrast the featured article Development of Grand Theft Auto V with the iOS version-history with its numbered (and numbing) repetition of the phrase "Apple announced that...." which does not give sufficient who/what/where/why/how context. FOARP (talk) 10:05, 18 May 2023 (UTC)[reply]
  • Oppose per JPxG. —Locke Coletc 04:08, 18 May 2023 (UTC)[reply]
  • Support. DFlhb has been the voice of reason on the side of keeping prose "version history" articles so I think that should count for something. The current wording has enough loopholes to drive a truck through and a directive to use "common sense" when no one can agree what's actually common sense to do in this situation. This is a good step toward actually defining terms and providing useful instructions instead of vague generalities. WP:NOTCHANGELOG is currently the shortest of the four points at WP:IINFO. It demands more instruction to serve its purpose. Axem Titanium (talk) 05:09, 18 May 2023 (UTC)[reply]
    What do you mean here by "loophole"? jp×g 08:48, 18 May 2023 (UTC)[reply]
  • Oppose taking instructions meant for video game manuals and putting them into our policies meant for all our articles. I never have much liked the way the video game fanboys do things anyway. They have terrible ideas including making content within articles notable. Huggums537 (talk) 10:16, 18 May 2023 (UTC) Reworded on 10:52, 18 May 2023 (UTC)[reply]
    Could you comment on the proposal itself instead of where it comes from? Aaron Liu (talk) 11:39, 18 May 2023 (UTC)[reply]
  • Support. This seems to be the clarification of changelog we need. On what Evelyn Marie said, I believe a summary of development is by definition of summary not a list of every version. Minor fixes aren’t notable just if lots of sources that routinely cover them cover them, that goes against ROUTINE. EVERY piece of software evolves through minor versions, and that does not mean we have to cover every single one of them. The iOS version history article does not include a list of every version/beta/patch, I do not see why we have to discuss it. Ubuntu version history may be a valid argument, if not for certain unimportant releases that the article pads with a ton of reviews, such as 14.10, so I still support this proposal. Aaron Liu (talk) 11:55, 18 May 2023 (UTC)[reply]
    Could you explain what you mean? Both the iOS and Ubuntu VH articles have subsections for every release. The iOS one is WP:SUMMARY style, but I guess that structure also makes sense for the Ubuntu article. How else would you organize it, if I'm understanding you correctly? DFlhb (talk) 18:11, 18 May 2023 (UTC)[reply]
    For example, 15.2 is not mentioned in the iOS article. For Ubuntu, I think releases like 14.10 should be skipped or restricted to a single line, and these lengthy review quotes should be limited to one paragraph if not removed entirely. Aaron Liu (talk) 19:07, 18 May 2023 (UTC)[reply]
    You have a fundamental misunderstanding as to how releases like Ubuntu 14.10 work, @Aaron Liu. 14.10 was a major release - it wasn't considered minor - they do releases based on the year and month. 14 indcates that its a release made in 2014, and the 10 indicates that it shipped in October. - Evelyn Marie (leave a message · contributions) 21:07, 18 May 2023 (UTC)[reply]
    I know how Ubuntu releases are numbered. However I thought they only released two times a year, once in April and once in October. Are you saying they also release in other months?
    And if there are minor releases in between, then we would also have no need to discuss Ubuntu, though my point still stands that "uninteresting" releases like 14.10 should be skipped have minimal coverage. Aaron Liu (talk) 21:36, 18 May 2023 (UTC)[reply]
    Then the article would be incomplete and would therefore not be encyclopedic. Additionally it would basically imply to readers that Ubuntu received far fewer releases than it did. That is not how a topic should be covered on Wikipedia. Massive release or not they still deserve coverage. - Evelyn Marie (leave a message · contributions) 21:42, 18 May 2023 (UTC)[reply]
    And regarding your minor releases comment no, there aren't minor releases in between - LTS releases do receive point releases throughout their life cycles, but Ubuntu doesn't release minor releases in between their major releases. - Evelyn Marie (leave a message · contributions) 21:44, 18 May 2023 (UTC)[reply]
    Massive release or not they still deserve coverage. Even if it did, it shouldn't be the absurd 5 paragraphs 500 words! There isn't much to cover, and one sentence would be enough. Plus, I don't think it should be covered, as Ubuntu releases every April and October, which also gives the reader the idea that the number of Ubuntu's releases is kinda meaningless. Such a release is kinda meaningless within the grand scheme of history, just like how we don't cover every Chrome release where the first number is bumped, for a more extreme example. Aaron Liu (talk) 22:18, 18 May 2023 (UTC)[reply]
    So doesn't everything I have said still hold true? What's your point? Aaron Liu (talk) 22:18, 18 May 2023 (UTC)[reply]

AFD touching on the scope of WP:NOT (lists of airline destinations)

Please see here for an AFD in which the applicability of WP:NOT to 14 articles listing the destinations served by different airlines is being discussed. FOARP (talk) 21:59, 19 May 2023 (UTC)[reply]