2023-11-02

Attending: Josh Moore (JM), Sanket Verma (SV), Jeremy Maitin-Shepard (JMS), Jonathan Striebel (JS)

TL;DR:

In this meeting, the attendees celebrated the acceptance of ZEP0002. The discussion revolved around potential changes to ZEP0, considering a phased voting approach and addressing implementation challenges. Additionally, topics included resolving conflicts in the Endian codecs to bytes pull request, updates to ZEP2 regarding index location, versioning, and tracking intermediate buffer sizes, and the addition of v1 and v2 specs to zarr-specs.

Updates:

  • ZEP0002 finally accepted! 🎉

Meeting Minutes:

  • Changes to ZEP0
    • https://github.com/zarr-developers/zeps/issues/52
    • JMS: Don’t think there’s gonna be any changes to ZEP1 now
    • JM: Could be 2 voting - but how do you get everyone to implement ZEP without voting?
    • SV: Yeah! Good point.
    • JMS: Don’t need to go overhead for small changes
    • JM: index_location is backwards compatible and maybe the best case scenario
    • JMS: But endian codec is not backward compatible
    • SV: Very natural to see this scenario coming up
    • JM: Architect building a building - they go through submittals - 20% increment - show the adoption percentage
    • SV: How would you define percentage?
    • JM: Voting could be in phases - reading phase - implementation change - grace period
    • Jonathan joins
    • JS: Voting encourages people to read the spec
    • JM: Setting a common calendar for the ZIC and ZSC - can help the author
    • JS: It was good to the response when we set the deadline - also the examples of implementation currently is good
    • JMS: Would be great to have a table of what part of spec they’re current implementing would be great
    • JMS: Having a compatibility table would be great - e.g. Neuroglancer doesn’t support boolean type
    • JMS: Once a ZEP is accepted the spec matters
    • JM: Looking at RFC for NGFF these days
    • JMS: Random reviews vs the expert group reviews
    • SV: If you’re going to implement the spec and how you’re going to implement the spec - Form a voting procedure around that
    • JS: Having a process definitely helped me to finsh the sharding - find it good as contributor!
    • JM: Having rebuttal would change the tone a lil’ bit
    • JS: Telling to vote before implementation is fine - as you can find things spec
    • JM: Having it defined in ZEP0 would be great!
    • JS: Doesn’t like the grace period - leave the door open a little
    • JS: Having an implementation phase would be good
    • SV: Reading notification during the voting phase - could be helpful
    • JM: Keeping a table would be helpful - 5 states
    • JMS: Three phases -
      • reading phase and express opinions
      • implementation phase and raise issues
      • solve issues raised in the last phase
    • JM: It’s clear we’re in agreement of phases/periods - intent
    • JM: People want general confidence from the audience that they’re moving forward
    • JMS: https://chromestatus.com/feature/6213121689518080
    • JMS: Getting formal feedback from the ZIC before the vote
    • SV: Let ZIC know when you’re going to put up the ZEP for voting
    • JM: Worst case scenarios - no-one read the spec and someone vetos the ZEP in the initial stage
    • JM: Roll call helps
    • JS: May not need a second vote - those are implementation details
    • JM: Add a different state - a pre-implementation checkpoint
  • Endian codecs to bytes
  • Changes to ZEP2:
  • Adding v1 and v2 spec to zarr-specs