Process, and meetings for subgroups

[dtig]

This was discussed in a previous meeting as a part of the GC Subgroup discussion. Following up on an issue so the discussion can be continued.

The process for forming subgroups, and operating them is varied across different proposals/repositories. For example, WASI, Debugging subgroups have official subgroup charters and meeting directories, and for the Interface types, SIMD proposals the formation of subgroups, and the process has grown more organically with notes linked to meeting issues. Open questions -

• Should there be a unified process that all the subgroups should follow?
• Where should meeting notes live?
• For the ones currently in individual proposal directories, what should happen when they are merged into the main repository? Should they live in the meetings repository instead?

[rossberg]

IMO it would be beneficial if we had a somewhat unified process, since that makes it easier to navigate the different subgroups for outsiders.

For meeting notes, I believe there were three main considerations:

• In favour of putting them into each group's repo:

  • closer to where the related online discussions happen (usually on the repo's issue tracker).

• In favour of putting them into the meeting repo:

  • easier to discover them, especially in the future, when the work of a group is done and its repo no longer used,
  • a cleaner story about what happens when merging proposal repos.

From my POV, the first argument could equally be applied to any other proposal discussed in the main group, so personally I'd favour the meetings repo.

[dtig]

I'm also in favor of a unified process, and wouldn't have objections to using the meetings repo. My one concern with using the meetings repo is all the additional notifications that folks following this repository will be auto subscribed to where currently this is only for the broader CG/WG meetings.

CCing other folks that run the subgroup meetings linked above for visibility/opinions. @dschuff @sunfishcode @jgravelle-google @tlively.

[sunfishcode]

A more unified process, and using the meetings repo, sound good to me.

[dschuff]

The meetings repo sounds fine for meeting notes. One reason we created a separate repo for debugging was the likelihood that we'd want to work on some stuff that wouldn't be part of any of the core/JS/Web specs (e.g. DWARF extensions), so a fork of the spec repo doesn't really provide any benefit. So for those cases, if and when "merging a proposal repo" happens (e.g. adding a new officially-standardized kind of spec), it would be more like creating a new directory alongside js-api and web-api. But that process would still at least mirror the process for "regular" proposals. So a uniform process of putting meeting notes in the meetings repo and each proposal or group putting design discussions and docs into its own repo would make sense.
I guess SIMD is now getting to the point where there will be 2 different spec proposals in flight, so having repos specific to proposals (rather than one for the "subgroup") makes sense.

[binji]

I agree that using the meetings repo for notes for all subgroups sounds good. So as a next step, are there notes that are currently in other repos that should be moved to the meetings repo?

[sunfishcode]

The WASI Subgroup has meeting notes in the WASI repo currently. What's a good path convention for them; should they go in $year/WASI-$month-$day.md next to to the CG meeting notes, or should we create a new top-level directory for them (eg. WASI/$year/$month-$day.md)?

[tlively]

My preference would be to have separate top-level directories for subgroup meetings.

[rossberg]

Maybe move the current dirs for main CG into a new top-level dir as well?

[binji]

That works for me. I think it's nice to see all the meetings flattened out into one list too, but we can still do that in the top-level README.md, as we do now.