Distinguish complete but unpublishable features from incomplete drafts

[ddbeck]

Summary

In a few places, we've dealt with a compat key but can't publish feature data for one reason or another. We should consider adapting tools (like stats.ts) or our overall workflow (e.g., add a unpublished directory with different semantics) to give us a more accurate look at which parts of the platform we've addressed.

Background

Prompted by this comment:

Can we put this in drafts instead, and update our scripts to count keys in drafts as handled? (But excluding auto-updated spec drafts, I think.)

Originally posted by @foolip in #2566 (review)

Problem

The current /features/drafts folder mingles feature data in two different conditions:

• Feature data that is incomplete (chiefly, the generated features computed from specifications)
• Feature data that is complete, but blocked by non-feature description work (e.g., upstream data quality issues or schema changes)

This means it's difficult to find keys that are unmapped and use them to describe new/unfinished features.

Examples

Here are some cases where this has come up:

• Add holding features for unspecified platform features #2566 — We have to figure out how to modify the schema to help consumers not show this data, but the keys are already dealt with in a useful way. Not publishing these features would do the trick.
• Add features for permissions policy and feature policy #2661 — We have to do upstream data work to make these features make sense with respect to caniuse.

[ddbeck]

Here's my half-baked proposal:

It would be nice if we could create features that are still subject to all the usual rules about features (e.g., discouraged statuses, etc.) and fall under the usual workflows (e.g., BCD upgrades), without having to park them in draft PRs or the less-strictly managed drafts folder.

Features in the drafts folder would work as they are: representing unfinished, possibly malformed data (e.g., having deprecated keys in non-discouraged features).

Features in an unpublished folder would resemble "normal" features and be subject to the full data requirements of an ordinary feature. The one exceptional thing about them is that such features (and any references to them) be scrubbed from the published packages.

This might also be useful for our early features workflow (when we come up with one), where we could reserve early features' IDs while there's specification or implementation work happening but before there's sufficient developer interest to publish a given feature.

[foolip]

Other than the generated drafts, it looks like we currently only have a single draft feature, File and directory entries. That means it's quite realistic to just use drafts and add whatever rules we want to it.

In other words, are we sure we need the drafts folder for unfinished, possibly malformed data? If not, then having one less state to worry about would be good I think.

Maybe we move draft/spec into gen or generated, and then start treating draft as regular features that aren't published? The name fits :)

[ddbeck]

Other than the generated drafts, it looks like we currently only have a single draft feature, File and directory entries.

I've opened #2633 to dispense with it, even.

In other words, are we sure we need the drafts folder for unfinished, possibly malformed data? If not, then having one less state to worry about would be good I think.

This is a good point. Hearing that, I'd suppose that draft PRs are the place where possibly malformed data should reside. It's not readily maintainable, so ideally those things should never be merged in the first place.