Proposal: New agenda template for public meetings

oliverdunk commented 5 months ago

We have discussed changes to the public meeting agenda previously in issues like https://github.com/w3c/webextensions/issues/145, but haven't yet tried any specific changes. I've been thinking about how we could change that and have written up a proposal for something we could try below.

Background

Our current approach to the WECG agenda has worked well, but has some limitations:

New issues and carry-over from previous meetings fluctuate significantly, meaning they can take up a disproportionate amount of time compared to other priorities.
The scope of what to discuss about an issue in each section of the meeting is poorly defined. This means we discuss some issues in too much depth when we should be working asynchronously.

This proposal is based on the premise that we should prioritize the following:

Focus	Motivation
Triage of new & updated issues from the community	The introduction of the WECG was a big step forward in giving developers a line of communication with browser vendors. This is something we want to preserve.
Issues which are prioritized for implementation and need cross-browser alignment before implementation starts	Unblocking implementation means we can see changes to the platform more quickly, and avoids the risk of shipping APIs we are not happy with the design of. Making sure these issues get room in the agenda ensures they can get timely feedback from the group.
Working towards deliverables like a specification	There is general agreement that a specification would make it easier to align on behavior, and therefore build cross-browser extensions. This also has the benefit of making it easier to demonstrate the impact of the group.

Template

This should be filled out at least 24 hours ahead of time by either the chair or a nominated person. We should heavily lean on more consistently creating “agenda issues” on GitHub where developers can propose topics to include. We should also be disciplined about not including more issues than the template allows, as this ultimately takes time away from other topics and is not sustainable.

3 minutes - Time for participants to join

2 minutes - Announcements

Announcements for the group

[Topics go here]

15 Minutes - Triage (Hard cut-off at 20 minutes past)

List approximately five issues that need triage here. We should discuss what action to take and give general design advice. We should not try to come up with an API design.

[Topics go here]

10 minutes - Timely issues (Hard cut-off at 40 minutes past)

Discuss anything nominated for the agenda related to PRs or deliverables. Also list issues likely to be implemented soon and needing timely feedback - these will often be nominated by browser vendors but could also be from a community member looking to submit patches.

[Topics go here]

All remaining time - Check-in on existing issues

List approximately five issues that are past the triage stage and have either (a) an API design to review or (b) a new question to discuss.

[Topics go here]

Rob--W commented 5 months ago

I created an agenda issue for the next meeting that uses this format, at https://github.com/w3c/webextensions/issues/535#issue-2113066231

maximtop commented 4 months ago

The notation "(Hard cut-off at 40 minutes past)" should be revised to "30 minutes past," considering that it follows a 20-minute segment by 10 minutes, totaling 30 minutes. Alternatively, the "10 minutes" allocated for timely issues should be adjusted to "20 minutes" to align with the mentioned cut-off time.

oliverdunk commented 4 months ago

The notation "(Hard cut-off at 40 minutes past)" should be revised to "30 minutes past," considering that it follows a 20-minute segment by 10 minutes, totaling 30 minutes.

Thanks for the feedback! This was actually intentional, to encourage us to pick issues that we aim to get through in 20 minutes, with the understanding that if it runs a bit over we'll allow that unless it gets to 40 minutes past. I think that worked fairly well today?

Definitely open to suggestions if even with that understanding we'd still like to change things up though.

maximtop commented 4 months ago

Ah, I see. I think noting it in the description is a good idea. I agree that the approach worked well today.

Could we also consider carrying over already nominated issues from previous sessions to the new one? This way, members wouldn't need to nominate issues again before every session. It would prevent those who nominated them from having to rush to re-nominate undiscussed issues immediately after a meeting ends. Additionally, having a complete list of all unresolved issues might make it easier to identify new issues for discussion.

oliverdunk commented 4 months ago

Could we also consider carrying over already nominated issues from previous sessions to the new one? This way, members wouldn't need to nominate issues again before every session.

I'll bring this up with the other editors that are involved in preparing agendas. I see the thinking here, I think we'd just need to find a way to make it work in practice :)

w3c / webextensions