Kicking off the Zarr Spec Committee

[d-v-b]

The recent update to the Zarr Governance introduced the Zarr Spec Committee. In its founding state, all members of the @zarr-developers/steering-council and @zarr-developers/implementation-council are members of the Zarr Spec Committee.

I would like to use this discussion to establish a framework for addressing the following concerns (1-3 are listed in the newly-updated core governance document):

1. Decision-making procedures (e.g. voting mechanisms, quorum requirements, and use of lazy consensus)
2. Membership criteria and review processes
3. Meeting cadence and participation expectations
4. The name of this body

For 1, I propose that we begin by copying the Apache decision making process. But I am open to other ideas.

I added item 4 because the natural acronym for "Zarr Spec Committee" is "ZSC" but this shadows the acronym already in use for the Zarr Steering Council. I propose that we introduce a new abbreviation, or a new informal name for this body. "Zarr Spec Team" or "Zarr Spec Working Group" would both be fine, but I'm up for other ideas.

Once we have a clear direction, I suggest we open a PR and draft a GOVERNANCE.md document scoped to this repository that outlines how we want this body to function.

For everyone in the steering council + implementation council, it would be helpful if you could:

• confirm your status: do you want to stay on as a member of the Spec Committee (or whatever we end up calling it)?
• weigh in on the issues 1-4 listed above.

Thanks for your time!

[d-v-b]

Another idea is "Zarr Spec Development Team".

In any case, I really would like to hear from other folks soon. I see getting these procedural matters resolved as a necessary precondition for fixing issues with the spec, namely the consolidated metadata problem.

[rabernat]

Thanks for kickstarting this Davis! I would like to remain on the spec committee.

1. Decision-making procedures (e.g. voting mechanisms, quorum requirements, and use of lazy consensus)

My opinion here is that some of the Apache-style governance stuff that works well for software projects (e.g. lazy consensus) may not be appropriate for the spec. The spec is different from software. It should be harder to change. However, it is currently too hard to change, so we need to find a middle ground.

Once the spec is in a good place, it should become very low maintenance.

My other strong feeling is that we need a clear time-bounded way to make decisions, something like an RFC, but more lightweight than the current ZEP process.

2. Membership criteria and review processes

I think a standard Apache-style "members nominate other members; acceptance by majority vote" will work fine here.

3. Meeting cadence and participation expectations

I would hope that a standing meeting is not necessary for the spec committee. Ad hoc meetings may be necessary. The most important participation expectation would be to participate in the RFC discussion process in a timely way. This is the biggest thing that has been lacking from the ZSC in the past.

4. The name of this body

Spec Working Group sounds fine to me.

[normanrz]

Thanks @d-v-b! I was going to send an email to initiate this, but you were quicker.

I would also like to stay on the spec committee. I think we should give people a deadline for opting-in to the new spec committee. Maybe 2 weeks until the end of the month. At that point, we should set up an inaugural meeting. I'll send an email to everyone.

1. Decision-making procedures (e.g. voting mechanisms, quorum requirements, and use of lazy consensus)

This seems to me the first big task for the spec committee: Writing a governance document for itself. Volunteers for creating a draft are welcome!

I agree with Ryan that we need a more lightweight process, that still ensures enough deliberation.

3. Meeting cadence and participation expectations

I would hope that a standing meeting is not necessary for the spec committee. Ad hoc meetings may be necessary. The most important participation expectation would be to participate in the RFC discussion process in a timely way. This is the biggest thing that has been lacking from the ZSC in the past.

I think a regular meeting (e.g. once a month) would be useful. We had the ZEP meetings for a while. I think they were great and we got a lot done.

Clear expectation for participation is very important. We need to define what that means exactly and what consequences inactivity will have as part of the governance doc.

2. Membership criteria and review processes

I think a standard Apache-style "members nominate other members; acceptance by majority vote" will work fine here.

Agreed.

Prior to the first meeting, we can already nominate new members. The meetings should be public anyways, so they would be welcome to join as visitors and can participate in votes as soon as they are voted in.

4. The name of this body

Spec Working Group sounds fine to me.

Agreed.

I wanted to add another agenda item that ties into no. 1: The Spec WG will be the steward of the core spec, but also the maintainer zarr-extensions repo. We should discuss how to set that up, e.g. setting up a subgroup, criteria for merging PRs.

[jbms]

I would also like to stay on the spec committee.

[joshmoore]

Thanks from my side as well, @d-v-b. Count me in.

A few thoughts on some of your points though not in any way comprehensive:

1. Decision-making procedures (e.g. voting mechanisms, quorum requirements, and use of lazy consensus)

I think Ryan did a great job of kicking off the lazy-consensus concept in getting ZEP11 out. My primary concerns to work through are probably visibility of votes (e.g., breaking through github verbosity) and availability windows (e.g., quick votes in the summer can be either a burden for the vote-launcher or a potential for disagreements if people are away).

2. Membership criteria and review processes

I'd make sure this conversation touches on the various GitHub permission levels since practically that's what will need to be modified when decisions are made.

3. Meeting cadence and participation expectations

This is one of the biggest issues that failed with the ZIC in my opinion: the ask may have just been too large, but declining regular attendance would have told us that sooner. For other bodies, I've seen examples of even tying voting rights to attendance. (In the one case, within IEEE).

[LDeakin]

Count me in as well! I'll see you all at the inaugural meeting.

[jhamman]

Choosing not to join the spec committee. Thanks all!

[manzt]

Choosing not to be on the spec committee as well, thanks!

[normanrz]

We had our inaugural meeting yesterday. Here are the notes: https://hackmd.io/@zarr/r16qTaLzze
Key points that we discussed:

• Name: Zarr Format Working Group
• Scope: Maintaining the Zarr Specification and the zarr-extensions repo
• Discussions on governance -> We'll work on a draft around lazy consensus
  • Merging PRs: 1 reviewer + 1 author
  • Making a spec release: vote of the WG (time-bounded: 1 month, default accept)
• Communication: default to async, clear expectation that WG members are responsive
• Membership criteria and process: Any member can nominate a new member; the WG should reflect the implementations
• Other
  • Build a way so that we can merge PRs without immediately updating the spec website (de-facto release)
  • Changing the rules on zarr-extensions: Extensions should have an implementation before getting merged