Tag focus-area-proposal issues with web-features' IDs

[captainbrosset]

Would you consider adding a mechanism to associate focus area proposal issues to their corresponding web-features?

Context

• Focus area proposal issues are filed each year, as new issues on the repository, by members of the web community, in an attempt to get their ideas accepted.
• web-features is a W3C WebDX Community Group project which aims at cataloging the developer features of the web platform, in order to provide hierarchical and summarized feature support data, in a developer-friendly way. One of the outcomes of web-features is the Baseline idea, which you can see at the top of MDN reference pages and on caniuse.com.

Proposal

When new focus area proposal issues get created on the repo, somehow link them to the corresponding web-features entry.
For example, the CSS Module Scripts proposal corresponds to the css-modules feature on the web-features repo (you can also see the feature in a simple way here).
If I had to propose a mechanism for doing this, it would probably be by adding a label to the issue on GitHub that looks like web-features:<the-feature-id>. So, in this example, it would be web-features:css-modules.

Why

The web-features project's main goal is to create a catalog in which, all features that developers can make use of to achieve particular end-user scenarios, have unique IDs, and where these unique IDs can then be referenced by other sources of open web data in the community.
The goal of the project is NOT to make a copy of the other data, and maintain it in our GitHub repo. For example, browser-compat-data points to web-features by using a web-features:<id-of-feature> tag. MDN will soon point to web-features too. The features listed in State of CSS/HTML/JS surveys are also being mapping web-features IDs. And so on.
Interop focus area proposals constitute another source of valuable data about features of the web platform. In particular, they provide valuable insights into what developers need, and how much they need it.

[captainbrosset]

Pinging @foolip who is involved in both Interop and web-features and will, I'm sure, have useful insights on this.

[jgraham]

I don't think we should do this with proposals; it seems like a lot of work, we might not have all the data we need in web-features, and the benefit for rejected proposals seems quite small. It might be different if we could confidently use the web-features data to map to other data sources like bugs or standards-positions, and so make more of the data gathering automatic, but we aren't there yet. Maybe next year :)

On the other hand I think writing down the web features that correspond to the final accepted proposals does make sense; it's a good test of whether web features are providing the correct granularity of data for this use case, and whether we have clean mappings for things that are not nesessarily implemented everywhere yet. In the long run it will allow us to be specific about what was included in each round of Interop in a way that's not easy to do currently. That said, I think we know as a practical matter that sometimes thing get subseted in Interop for practical reasons (consider pointer events where we can only test mouse for infra reasons), so I don't think the mapping will ever be totally clean.

[captainbrosset]

I don't think we should do this with proposals; it seems like a lot of work

Roughly how many proposals get submitted each year? I get the sense that it's in the range of 100, which doesn't seem to me like so much work. People know the web-features repository well (I'd gladly volunteer) could do this. It also doesn't matter so much if all proposals are tagged right away. This is something that can happen over time.

the benefit for rejected proposals seems quite small.

I tend to disagree on this point. #513, for example, was rejected for interop 24, but has 69 positive reaction emojis and 36 comments. I know interop must prioritize and understand that there are very valid reasons why this one might have been rejected. But, attaching it to a web-feature ID would provide some developer need signals for this feature. Just like attaching State Of XYZ survey questions to web-feature IDs makes it possible to go from a feature to a set of data showing developer interest or lack thereof.

[bkardell]

Roughly how many proposals get submitted each year? I get the sense that it's in the range of 100, which doesn't seem to me like so much work. People know the web-features repository well (I'd gladly volunteer) could do this. It also doesn't matter so much if all proposals are tagged right away. This is something that can happen over time.

It's hard to predict but yes historically/so far, "> 100" is a good broad range.

To be clear, the group was not opposed to it being done, it was opposed to this group (some overlap, but not much) taking responsibility to do that, and especially if it got in the way of existing work/timelines. Its welcome to have that metadata and I was going to suggest the dx group might try to add it/focus on it a bit since the window for proposals is relatively small.