Organizing developer signals around features

[foolip]

In web-features we're defining the platform as a set of features, and determining a Baseline status for each. This is being used on MDN and caniuse.com already. Additionally, web-features can be used to organize other data sources. A good example of this is web-platform-tests, where we can annotate tests and search for them.

This repo is about developer research, and I wonder if we could organize developer signals around web-features. In the most basic form, that could mean maintaining a list of links indicative of developer interest or sentiment. I expect the Chrome team would use such signals for prioritization, and it would also be a helpful resource when evaluating proposals in the Interop program.

To make this concrete, the "data" might be something along these lines:

BroadcastChannel

• https://stackoverflow.com/questions/28230845/communication-between-tabs-or-windows
• https://2022.stateofjs.com/en-US/features/browser-apis/#broadcast_channel

Subgrid

• https://mdn.dev/archives/insights/reports/mdn-browser-compatibility-report-2020.html#findings-css-grid
• https://2020.stateofcss.com/en-US/opinions/#currently_missing_from_css
• https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins
• https://2022.stateofcss.com/en-US/usage/#interoperability_features_freeform
• https://2023.stateofcss.com/en-US/usage/#css_interoperability_features

I think we should start with a broad definition of "signals" but the main categories I can see are:

• Survey results: State of X surveys, MDN short surveys, or any other public survey results.
• Repo issues with a lot of reactions, or similar. An example of this approach can be seen in Interop 2024 Reactions.
• Starred bugs

Would this be useful to collaborate on in the WebDX CG?

cc @dontcallmedom @tidoust @captainbrosset

[foolip]

Not to get too far ahead of things, but I've discussed with @devnook and @robnyman how we might organize this, and we have some ideas:

• An issue per feature web-features for discussion (probably excluding very old/stable features)
• A YAML file or similar to list URLs that we've decided are noteworthy after discussion
• In some cases, "tagging" of things with web-features instead of us linking to them. Tagging survey questions with web-features Devographics/Monorepo#358 is an idea in that direction. Labels on other GitHub repos would be another case.

[captainbrosset]

My 2 cents: Yes, I think it would be useful for the WebDX CG to collaborate on this. I would love for web-features to also act as a simple way to get to developer signals and to also make it easier for web devs to give their signals.
So, this needs to be a 2 way street, where browsers can easily check how much devs want a particular feature, but also where devs can easily find where to even vote for a feature. See also web-platform-dx/web-features#591.

[foolip]

@captainbrosset great to hear you think this is worth exploring. Do you have thoughts about how best to organize this at a technical level? I'd like to get started trying things out for a few features, and what I'm currently thinking is a new repo where we use either an issue or discussion per feature for open ended discussion, and checked-in YAML for the signals that we (repo maintainers/reviewers) think are noteworthy. GitHub actions could update the issues/discussions with the links for each feature to have a more readable view of it too.

[tidoust]

The approach you suggest looks good to me, @foolip. GitHub actions could perhaps work the other way round, and update YAML files from some specific structured list near the top of the issue/discussion to make maintenance less technology savvy, making sure that the list was written by someone who has appropriate rights on the repository to avoid integrating spam.

FWIW, not the exact same thing, but we have something similar in place for TPAC breakouts repositories: issue descriptions are the source of truth and are processed and validated by GitHub Actions whenever they are updated: see TPAC 2023 breakouts repository.

I think that you have the appropriate rights to create a repository under web-platform-dx, so if you want to take a first stab at it immediately, feel free to go ahead! In the meantime, I propose to add it to next week's WebDX CG meeting agenda to raise awareness, make sure everyone finds it a useful thing to collaborate on within the group (I suppose so, and see this got raised last week already but minutes do not seem to include a clear "let's do this!" message), and gather feedback on the approach.

[foolip]

@tidoust I indeed seem able to create repos, I didn't know that :) I was thinking "developer-signals" as the repo name, does that sound reasonable?

Regarding the source of truth (issues or repo contents) I discussed this a bit with @devnook and @robnyman earlier. One benefit of in-repo is that we'd use PRs for reviews which means we "control" the source of truth in a way that many of us (admittedly more git savvy) are familiar with. But maybe there's a place for both. If there's some state that we want to make very easy to edit via issues (labels and checkboxes come to mind) then we could mirror that the other way. Bug star counts is another thing where the source of truth is not in the repo, so we can't build everything around the assumption that the repo is ground truth anyway.

[tidoust]

@tidoust I indeed seem able to create repos, I didn't know that :) I was thinking "developer-signals" as the repo name, does that sound reasonable?

Ah, naming, that's also why I felt I would let you create the repo ;) "developer-signals" seems good. The other name that comes to mind would be "web-features-signals", which is longer but more specific if data ends up in a released package (developer signals could be about many things). We can always rename later on as we did for the "web-features" repo in any case!

[devnook]

I like the web-features-signals name, because it is also not audience-specific. While the initial target group is developers, this name focuses more about the subject of the signals rather than submitter.

[foolip]

I have now created https://github.com/web-platform-dx/developer-signals with signals.yml as a very minimal starting point.

On the naming, I would be happy with anything, but chose to not put "web-features" in the name initially because I suspect that some signals worth tracking will turn out to not map neatly to existing features. For example, questions in the style of How happy are you with the general state of web technologies? seem worth tracking across surveys, but don't map to a feature, or even a feature group other than "the web". Still, I let the README say "To the extent possible, signals will be organized around web-features" because that's what I'd like to focus on initially.

[foolip]

@tidoust can I present this at the next CG call?