2023-04-06
Attending: Sanket Verma (SV), Ryan Abernathey (RA), Jeremy Maitin-Shepard (JMS), Ethan Davis (ED)
TL;DR:
In today’s ZEP Meeting, we worked on the text to kick off the review process for ZEP0001. After reviewing the document and making a few necessary changes, JMS created an issue to notify the ZIC and ZSC that ZEP0001 has finally entered the review phase. Please check the relevant issue: https://github.com/zarr-developers/zarr-specs/issues/227.
Updates:
- ZEP1 is ready for review after merging #224
Meeting Minutes:
- SV: ZEP0001 is ready for review
- RA: What does ZIC think of the implementing the spec? We should ask them!
- JMS: Sounds good!
- RA: We can use the main issue to cast the votes, and open separate issues for additional concerns as having everything in a singe issue will clutter it
- RA: Are we expecting a lot of feedback and then we would need to edit the spec? Because we’ve already did a lot of work to reach the current state of the SPEC
- JMS: Think people who haven’t been involved in the SPEC process so far would not be too much concerned with the details
- ED: Has there been any involvements from the ZIC?
- RA: Not much!
- ED: Then maybe it’s gonna be clarifications and similar questions
- RA: In my experience, you can design as much you want but real issues starts coming up when you start implementing it
- ED: Yeah!
- JMS: It not easy to get a large group of people to agree on a same thing at a same time!
- RA: Do we have a reference implementation of V3?
- SV: Yeah, Zarrita!
- RA: Need to provide some clarifications on the voting mechanism
- They could vote to approve
- They could to abstain
- And they could vote to veto
- RA: Provide guidance on the implementation as well
- ED: In OGC, you can say no but with the comments
- RA: We should plan that there’s no veto!
- JMS: Need to avoid the case where the implementors start working on a new spec on their own - also a fact that this is a community process - you can’t force people to implement something new if it isn’t helpful for them - instead you can help them with their additional use cases
- ED: Why veto and why just ‘No’?
- RA: That’s for other ZEPs not for ZEP0001 because it’s like a constitution of Zarr
- ED: The veto is contentious issue
- RA: Is there a process to respond to the feedback? Is there a time period for that?
- SV: We should accomodate all of the feedback in a month’s time
- ED: Is the vote going to be, ‘Yes’ we’re moving forward with it and there’s gonna be a separate discussion for the implementation? - OGC have a public comment period
- RA: There are heavy handed process like OGC, ISO but we don’t want to use them; we just made a process for our project and the community to reach a consensus - like the idea of comment period from the council and they have a month to solicit their feedback - and after that we’ll take a vote
- JMS: If people wanted to comment, they’d have already done so
- RA: I’d love to think so but all the implementors are busy and they might be waiting for someone to come to them review the spec - the downside of doing this is we’re going to present this as a take it or leave it and that’s not fine given Zarr is a commmunity owned OS project!
- JMS: What does leave it mean? They’ll not upgrade to V3 from V2 - Is it fine?
- SV: I know some folks from the council couldn’t keep up with the progress and they’ve been waiting for the SPEC to go into the review phase
- RA: It’s been in the review phase forever! - would like to see robust handling of the extension points - getting behind the idea of 1 month time
- ED: Release candidate for the extension?
- ED: Does approval means that the SPEC will be 3.0 or 3.1.0 or 3.0.1?
- SV: It’s gonna be 3.0
- JMS: How about the folks who were involved during the development of the SPEC?
- SV: Will take care of it after the voting period
- ED: It’s a good to list the contributors!
- SV: Does everything seems fine?
- JMS: Yes!
- ZEP0001 Review issue: https://github.com/zarr-developers/zarr-specs/issues/227 🎉