Skip to content
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

Merged
merged 3 commits into from
Sep 17, 2020

Conversation

ddbeck
Copy link
Collaborator

@ddbeck ddbeck commented Sep 11, 2020

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.

@ddbeck
Copy link
Collaborator Author

ddbeck commented Sep 11, 2020

@foolip would a policy like this satisfy for data removals such as those in #6658? I tried to tailor it narrowly, but I'd like your impressions as someone who's been dealing with this directly.

@foolip
Copy link
Collaborator

foolip commented Sep 11, 2020

@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.

@jpmedley
Copy link
Contributor

@foolip Chrome 70 was released in stable on September 4, 2018. It looks like anything older than that could be removed.

@foolip
Copy link
Collaborator

foolip commented Sep 11, 2020

Thanks for looking that up @jpmedley! That means this would allow removing the flags I was just dealing with, which is great!

@ddbeck is there a process for getting this guideline adopted? Just wait for feedback for a while?

@queengooborg queengooborg added the docs ✍️ Issues or pull requests regarding the documentation of this project. label Sep 11, 2020
@Elchi3
Copy link
Member

Elchi3 commented Sep 12, 2020

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).

other considerations may result in flag data continuing to be relevant, even after the guideline conditions are met.

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

Now Proposed
streams-1 streams-2

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.

@ddbeck
Copy link
Collaborator Author

ddbeck commented Sep 14, 2020

@ddbeck is there a process for getting this guideline adopted? Just wait for feedback for a while?

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.

@ddbeck ddbeck merged commit 59a1d80 into mdn:master Sep 17, 2020
@ddbeck ddbeck deleted the document-flag-removal branch September 17, 2020 10:21
@foolip
Copy link
Collaborator

foolip commented Sep 18, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs ✍️ Issues or pull requests regarding the documentation of this project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants