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

Agenda for Sept 5, 2024 #692

Closed
nairnandu opened this issue Sep 4, 2024 · 2 comments
Closed

Agenda for Sept 5, 2024 #692

nairnandu opened this issue Sep 4, 2024 · 2 comments
Labels
agenda Agenda item for the next meeting

Comments

@nairnandu
Copy link
Contributor

Here is the proposed agenda for the meeting on Sept 5th, 2024

  • Review backlog of items to call for proposals on Sept 12th
  • Mechanics of sharing signals and proposal selection
@nairnandu nairnandu added the agenda Agenda item for the next meeting label Sep 4, 2024
@nairnandu
Copy link
Contributor Author

Attendees: @nairnandu, @meyerweb, @bkardell, @ChrisC, @dandclark, @zcorpan, @jgraham, @chrishtr, @tantek

Notes

  • Review backlog of items to call for proposals on Sept 12th
  • Mechanics of sharing signals and proposal selection
    • nairnandu: sharing a template for how we might want to share signals for focus area proposals
    • jgraham: champions are for focus area, not for individual proposals. We can maybe start with a doc.At least for the early stages, we could use a doc
    • nsull: centering the conversation around the value of each focus area would be valuable
    • bkardell: what do we want out of the signals? Is it just to share them?
    • nsull: ton of work was done last year to look at signals for each area. The idea was to collect and share them.
    • jgraham: once we have a list of proposals that are being championed, we can ask each other for any signal that is not owned by the champion (like a standards position from another org). ultimately, we are prioritizing focus areas
  • Tagging web features for focus area proposals - Tag focus-area-proposal issues with web-features' IDs #693
    • nairnandu: this is very last minute, but wanted to see if we can discuss the idea and not the specific mechanics
    • jgraham: for accepted proposals, it would be nice to link web features. Dont think we should require proposal authors to make that link.
    • nsull: could potentially be a lot of work. Could the web feature team maintain that mapping? Is there any benefit in doing it?
    • jgraham: its not really in scope for the web-features project. Linking the proposal to a web-feature makes it unambiguous which features made it to Interop
    • bkardell: we are going to end up discussing groups of things as web features. The benefit is tying all of this information together
    • chrishtr: there's also the benefit that we can tie it to survey data and potentially other signals in future
    • jgraham: that is the future direction, we are not there yet. Would love to see web-features and standards positions be linked as an example, in future.

@captainbrosset
Copy link

jgraham: for accepted proposals, it would be nice to link web features. Dont think we should require proposal authors to make that link.

Agreed that asking proposal authors to do this doesn't seem good, and aiming for something more automated in the future is really what we need. In the meantime (and while the web-features repo continues to grow), I wouldn't mind helping out and doing this manually.

nsull: could potentially be a lot of work. Could the web feature team maintain that mapping? Is there any benefit in doing it?

Can you explain what you mean by a lot of work? I'd like to get a sense for the volume of work you're expecting here.
The web-features team could certainly help to start things of, at least as an experiment, and as a forcing function to see how/if something more automatic can eventually be put together.
The benefit of doing this is tying developer signals to web-features entries. Browser vendors need web dev community feedback in order to prioritize the right things on the web platform. Things like State Of HTML/CSS/JS surveys, upvotes on bugs, interop proposals, WebWeWant wants, etc. are many developer signals that browsers can rely on to inform future decisions.
But, without a common way to talk about features, and without a hub that allows you to link to these things, it's kind of hard.
I think web-features has the potential of cross-linking a lot of useful data.

chrishtr: there's also the benefit that we can tie it to survey data and potentially other signals in future

+1

jgraham: that is the future direction, we are not there yet. Would love to see web-features and standards positions be linked as an example, in future.

I proposed this a while ago in WebKit/standards-positions#357 and mozilla/standards-positions#1034, but these didn't get very far because both positions repos want to use issue labels to track the information about a position and didn't seem receptive to the idea of maintaining new web-features labels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda Agenda item for the next meeting
Projects
None yet
Development

No branches or pull requests

2 participants