-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add irrelevant flag data removal data guideline #6670
Conversation
@ddbeck this looks great, thank you! I haven't checked how old the flag data is that I've run into, but think it is older than two years. |
@foolip Chrome 70 was released in stable on September 4, 2018. It looks like anything older than that could be removed. |
I like this (conservative) approach to remove flag data. With the two conditions you are introducing, it seems to me that data will still make sense and useful to web developers (which is what drives BCD ultimately).
I think this is great to mention as well. I think if someone proposes a scripted update to BCD to apply this new rule broadly, they should probably check any situation where the support data contains extra data such as notes. (maybe we want to specifically mention notes in this sentence). The following isn't even MDN data, but I leave it here for illustration for the impact I think it has on the caniuse rendering. https://caniuse.com/?search=streams
On MDN, as you've discussed, the impact should be even more minor given the current rendering displays historic flags only after you've clicked the drop down. I say should, because we haven't solved #1596 yet. So, another gotcha when mass updating historic flag data, is to look into the ordering of our support array. The ordering is unfortunately relevant to the current MDN rendering. caniuse has the better (guaranteed chronological) rendering. I share all the arguments from the data maintainer's point of view that have been shared in the mentioned issues and I hope this will make things a bit easier. Thanks for thinking this through in a more nuanced way than just dropping all flag data like it was talked about before. r+ from my side. |
I didn't really have a plan before. Since it sounds like this guideline is well-received, I don't expect to revise it. But just in case, I'll leave the PR open until at least the end of my work day tomorrow. If there are no objections, I'll merge it then. |
Thank you @ddbeck for getting this done. I'll be happily removing old flag data now when it gets in the way of fixing a problem with the rest of the data. |
This PR proposes a limited flag data removal policy, inspired by the Removal of irrelevant features policy.
The intent here is to allow judicious removals of valid but historic flag data. This should make it easier for contributors to improve data, such as in #6658. Also, please see #3318 (comment) for more about the issue of flag data in general.