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

Status of this repo #4

Open
foolip opened this issue Jun 27, 2024 · 2 comments
Open

Status of this repo #4

foolip opened this issue Jun 27, 2024 · 2 comments

Comments

@foolip
Copy link
Collaborator

foolip commented Jun 27, 2024

Since there hasn't been much activity here, I want to make clear what the current status and plans are.

In terms of organizing survey results around web-features, Devographics/Monorepo#358 is the most concrete work, and in Devographics/entities#14 I did it with for one "entity". I think doing this for all State of HTML entities would be the obvious next step.

However, I am planning parental leave from August to January and realize I won't have time to finish anything I start, so I've left this project sit idle for now. I don't expect to do any work on it this year, but do think it's promising and want to come back to it next year.

@captainbrosset
Copy link

Thank you, @foolip, for starting this repo and investigating in the direction of linking survey results with web-features.
I do agree that this is promising. Developer signals are out there for browser vendors to use, and bringing visibility and structure to them feels like a good mission for WebDX, by using the web-features IDs.
One thing to consider in the future is: is it enough for us to establish a mapping between features and survey question URLs? Or, should we think about something more verbose, where we can also leave a comment, and overall sentiment/score, that summarizes the developer signal.

As a consumer, finding all of the surveys that do mention feature Foo is nice, but being able to find the list of features, out of the entire repo, that score a certain way, and why, would be amazing.

@foolip
Copy link
Collaborator Author

foolip commented Jun 27, 2024

We discussed this briefly in a meeting a few months ago. I silently assumed it would be too hard to agree on how to interpret developer signals so my initial direction was to merely record the signals. However, if there is appetite for it, I think something more editorial which includes a summarized low/medium/high ranking would make this much more useful.

Internally at Google, we already make a judgment about low/medium/high developer signals during prioritization, so I know it can be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants