Talk:Backward compatibility

Wiki Education Foundation-supported course assignment

This article was the subject of a Wiki Education Foundation-supported course assignment, between 28 August 2019 and 20 December 2019. Further details are available on the course page. Student editor(s): Zachary Sparacio.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 15:12, 16 January 2022 (UTC)

Examples

@La marts boys: These examples are unsourced. Unsourced material may be challenged or removed. Should these examples be sourced to primary sources or sources that only show their verifiability but not their significance, they may be challenged or removed too, per WT:V consensus as explained on "self-sourcing examples". BrightRoundCircle (talk) 11:01, 11 July 2016 (UTC)

@BrightRoundCircle:, a challenge in terms of WP:BURDEN requires a good-faith belief that the removed items are impossible to verify. Have you made your part of the deal and tried (but failed) to verify the claims that these items are high-profile backward compatible by, for example, reading the linked articles? (which in most if not all cases happen to discuss the relevance of such compatibility). Diego (talk) 09:34, 12 July 2016 (UTC)

@Diego Moya: Are you sure the burden is on me to verify the claims? I might be wrong here (I've been very, very wrong in reading a consensus before), but it seems WP:BURDEN says "The burden to demonstrate verifiability lies with the editor who adds or restores material" and "Any material lacking a reliable source directly supporting it may be removed and should not be restored without an inline citation to a reliable source." If I'm not reading it wrong, it seems the person adding or restoring unsourced claims needs to cite them. BrightRoundCircle (talk) 10:29, 12 July 2016 (UTC)

No, the burden to verify challenged content lies in those wanting to include it. But there are two separate steps, the challenge and the verification. In order to remove those facts with a challenge based on the BURDEN policy, you have to state that you believe in good faith that the content is unverifiable; it's not enough to check that they currently lack an inline reference. This is similar to performing a WP:BEFORE check before requesting an article deletion. If you truly believe that those facts are impossible to verify and assert so, then you can remove the content under that policy, and the burden is on those wanting to include the content again. But so far you don't have stated your belief that it is impossible to find references for the content, only that the current format of the article is not conformant with the sourcing guidelines, so BURDEN does not apply (yet). Diego (talk) 10:41, 12 July 2016 (UTC)

I dunno man, I know I've been wrong on this before, but I can't find any info on having to state that I have to say I believe something is unverifiable to remove it. All I can see is (paraphrased) "if this is unsourced, it can be removed, and it has to be sourced to be restored." I believe, in good faith, that these examples are too trivial for inclusion. I don't believe they're unverifiable, but I can't see how I have to show that they're unverifiable in order to remove them. BrightRoundCircle (talk) 10:55, 12 July 2016 (UTC)

I think this is best put in WP:ONUS - "The onus to achieve consensus for inclusion is on those seeking to include disputed content." BrightRoundCircle (talk) 11:06, 12 July 2016 (UTC)

(edit conflict)Please read BURDEN carefully ;-) "When tagging or removing material for lacking an inline citation, please state your concern that it may not be possible to find a published reliable source for the content, and therefore it may not be verifiable.[(and see the note as well)]. If you think the material is verifiable, you are encouraged to provide an inline citation yourself before considering whether to remove or tag it".

BURDEN is for those cases where the verifiability of the content is at doubt (i.e. when you think that no reliable source in the world would make the claims included in the article in the terms that hey have been made), not for all instances where you want to remove content for styling reasons. In this case you don't think that the content is unverifiable, so BURDEN is not the policy to apply, and WP:CONSENSUS is. Diego (talk) 11:07, 12 July 2016 (UTC)

Okay, so does this mean I can remove these examples, which I believe in good faith are trivial and don't contribute to the article, according to WP:ONUS? I don't want to misinterpret things again, but it seems WP:ONUS says the material should be removed until consensus is reached on how (or if) to include it.

I'm really sorry for taking up so much of your time, and apologize for misinterpreting policy all the time. BrightRoundCircle (talk) 11:11, 12 July 2016 (UTC)

(edit conflict) And regarding WP:ONUS, the content was already there, it is you who wanted to remove it and have had your edit reverted by several editors. I agree that the section could use some cleanup, and I'm not sure about the relevance of those camera lenses with respect to other models of lenses from other companies. But complete removal of the whole section is against WP:PRESERVE - many of those examples are well-known for their backward compatibility, to the point of making it a major sales point, and thus belong in this article. Diego (talk) 11:14, 12 July 2016 (UTC)

"Already there" is subjective, though; it was tagged for removal for over a year, and a cursory glance at the article history shows that the list of examples grew and shrank each year from 2005 onward somewhat arbitrarily. I'm not sure these examples belong in the "finished" article; why would readers need a list of arbitrary software and hardware with backwards compatibility? Wouldn't that be better in "List of backwards-compatible software and hardware"? Do I really have no recourse but to let things stay because "they were already there"? That seems very problematic. BrightRoundCircle (talk) 11:28, 12 July 2016 (UTC)

I've organized the section in groups of similar items; that should highlight the logic behind each inclusion, and make it clearer why those particular objects have been included and not others. It should also prevent the section from growing in random directions.

If you know a bit about the reasons why companies decide to keep backwards compatibility for their line of products, and examine the cases here presented, you'll see that this list is in no way arbitrary. In all those markets, being backward-compatible have provided a competitive advantage.

Of course it would be great that we expand the section and include all the relevant details of how each product's backward compatibility was significative for its adoption, and how they shaped its respective industries (although right now, the interested reader can already follow the links to the respective articles and learn about them there). But such expansion won't happen if you remove the WP:IMPERFECT content without trace and force editors to start all over again. Pruning a plant is required to make it grow healthy, but you must prune the bad branches, not the good ones. Diego (talk) 11:42, 12 July 2016 (UTC)

Would you object if I just cut-and-paste the section into List of backward compatible systems and replace it with a wikilink to that article? BrightRoundCircle (talk) 11:48, 12 July 2016 (UTC)

Why would you want to do that!? O_o The content where it stays now is surrounded by the context of the topic description. As a stand-alone list, it would be devoid of any context. How is that an improvement?

Usually, lists are only split up to stand-alone articles when they are too large to be included in the article that covers the topic where they belong. Diego (talk) 11:53, 12 July 2016 (UTC)

The list section is longer than the prose... BrightRoundCircle (talk) 11:54, 12 July 2016 (UTC)

That would be a wonderful reason to expand the prose, not to remove the list. ;-) Diego (talk) 12:01, 12 July 2016 (UTC)

And the list is not longer that the prose. The article introduction plus first section add up to 800 words, and the list has about 550. Diego (talk) 12:06, 12 July 2016 (UTC)

You can see the difference between major/important/significant examples (FM radio, x86, Wi-Fi) and trivial examples (Sega 32X, PCI Express 2.0, IBM 7080). I don't doubt these examples are verifiable, but they add very little to the article. BrightRoundCircle (talk) 15:17, 12 July 2016 (UTC)

Ok, it could make sense to remove some of those unless a secondary source states their significance. On the other hand, for thinks like the Windows and Mac OS systems, Playstation and Gameboys, USB, TV formats and telephone networks, their backwards compatibilities were HUGE things. Diego (talk) 15:23, 12 July 2016 (UTC)

Yeah... I'm not gonna remove anything because of my previous misinterpretation of the consensus, but this sort of example-creep does bother me. BrightRoundCircle (talk) 16:07, 12 July 2016 (UTC)

I think the reason why the reasoning around "In popular culture" sections doesn't apply to this article is because the appearance of one topic in a series episode is usually a trivial part of the narrative, whereas the fact that one commercial product is backwards-compatible is often a primary attribute of such products, which largely define them. Diego (talk) 16:16, 12 July 2016 (UTC)

Predictably, more and more examples are added with little or no references, and little or no encyclopedic value. BrightRoundCircle (talk) 19:46, 3 December 2016 (UTC)

Inaccuracy about x86 & 8080 example

The article states that Intel x86 is backwards compatible all the way back to the 8080. I'm almost certain this is not the case and that the binary backwards compatibility is only back to 8086/8088. See this Retrocomputing StackExchange article for instance. I'd fix but at the moment I don't have time to dig up proper references. BrandyLova (talk) 04:23, 15 September 2017 (UTC)

Creation of Drawbacks category or expansion of Costs

I have some sources discussing the rise of digital storefronts as making backwards compatibility obsolete. I was thinking of re-naming the 'Costs' section 'Drawbacks', both to strike a balance with the 'Benefits' section before it and to introduce some of the broader criticisms of the feature not pertaining to the literal costs. Any input on this would be very welcomed. Zachary Sparacio (talk) 01:44, 7 October 2019 (UTC)

Roadmap "usually"?

The article claims that forward-compatible products "usually" have a roadmap for this. But in many cases, including the cited example of FM mono to stereo, the older technology was introduced without the new technology in mind, and forward-compatibility was only added as a requirement when the new technology was developed. KevinBTheobald (talk) 06:47, 9 May 2020 (UTC)

Backwards vs backward

Is it okay to make "backwards compatibility" the primary name of the article? I googled both "backwards compatibility" and "backward compatibility" and the former appears to be more common. --AllOriginalBubs (talk) 16:41, 19 May 2021 (UTC)

I don't see how you could possibly make that determination from a Google search. Google, like most search engines, treats words like "backward" and "backwards" as interchangeable in order to maximize the number of search results. Martin IIIa (talk) 20:33, 4 September 2022 (UTC)

Google's ngram viewer shows that, in books at least, "backward compatibility" is far more common than "backwards compatibility".[1] Same for "backward compatible" vs. "backwards compatible".[2] CodeTalker (talk) 20:46, 4 September 2022 (UTC)