Links to unwritten deprecated API reference

[hamishwillee]

IMO it is very unlikely that we will ever back-fill the bulk of deprecated APIs because they are not a priority.

Propose that we remove any links in BCD for deprecated APIs that have not been written. These can always be added back in if the docs are ever written. I am not suggesting that we do this methodically, but that we accept bugs to remove such links as "valid" and act on them when we can be bothered. My reasoning is that if the links are broken and unlikely to be fixed they are visual clutter, and just an opportunity for people to raise bugs that we realistically won't fix.

Not sure if we should do the same for MDN content. I guess it comes down to whether we think we should still request content for deprecated APIs? I think we should just leave the content alone for now.

@wbamberg @sideshowbarker @ddbeck ?

This came from mdn/content#14865

[sideshowbarker]

heads up to @queengooborg as well

[hamishwillee]

@queengooborg Any thoughts on this?

[queengooborg]

I'm always down for a data cleanup! I think this is a great project for us to tackle, and like @teoli2003, I additionally think it would be great to clean out all broken MDN URLs within BCD.

[hamishwillee]

, I additionally think it would be great to clean out all broken MDN URLs within BCD.

@queengooborg @teoli2003 I don't agree. To me the key is that the link should not be displayed as a link if the document does not exist. I'd rather we followed the path implied below by https://github.com/mdn/content/discussions/14869#discussioncomment-2553867 and automate the rendering.

My reasoning is that the links from BCD are valuable, but no one is going to go back and add docs links with any kind of reliability. Further, if I am documenting something new I start with BCD and add the links to the docs I plan on creating. If that is blocked you'll be adding an additional update and review cycle to BCD for little value.

That said if we know that docs are unlikely to be created - such as deprecated then I think we should purge those from BCD. I think we have broad agreement on that, which is what I needed.

[queengooborg]

I see your point. My reasoning for wanting to clean out URLs in BCD is because while we may be able to perform some form of smart rendering on MDN, we will still be leaving the other consumers of BCD (CanIUse, VSCode, etc.) with all of these 404 URLs. This means that we'll leave them with the additional work of having to filter out the bad URLs.

There might be some way that we can automate the addition of MDN URLs in BCD, which might resolve the issue?

[hamishwillee]

There might be some way that we can automate the addition of MDN URLs in BCD, which might resolve the issue?

Perhaps. Or you might provide a snapshot of the "links in MDN that should be ignored" information for those other services to use.

Or to put it another way - sure, if we can find one that doesn't end up with a worse result than we have with all the broken links.

[ddbeck]

BCD has an issue open, which speaks to some of the questions involved generally: mdn/browser-compat-data#11291.

For a long time, it would've been difficult to figure out which MDN URLs even existed. But with mdn/yari#5015 and practically all of the HTML gone, it would now be practical to create a workflow on mdn/content similar to https://github.com/mdn/browser-compat-data/blob/main/.github/workflows/add-push-artifacts.yml. Preventing 404s in BCD would then be pretty straightforward:

1. Fetch mdn/content's main HEAD content inventory JSON artifact.
2. Confirm that every mdn_url in BCD exists in the content inventory.