2023-05-17

Attending: Sanket Verma (SV), Davis Bennett (DB), Ward Fisher (WF), Eric Perlman (EP), Norman Rzepka (NR), Josh Moore (JM), John Kirkham (JK), Dennis Heimbigner (DH), Jeremy Maitin-Shepard (JMS)

TL;DR:

SV initiated the meeting by sharing important updates and discussing the best way to take and keep notes for the community meetings. After this, NR had some questions on ZEP0001 implementation. The meeting ended with the SV discussing various voting tools and DB on storing the sampling grid in the bio-imaging domain.

Updates:

ZEP0001 is finally accepted! 🎉
- Implementors can start working on their implementations
- Will be moving the ZEP0001 under the new Accepted section
- Will move it under Final section once we have atleast one complete reference implementation
Ongoing updates to https://zarr.dev/ – opinions & PRs welcome.

Meeting Minutes:

Community meeting notes
- collaborative notes or not?
  - No one offered to help!
- to have them after the meeting or during the meeting?
  - All: Community members like to read the notes during the meeting
  - JK: conda-forge & conda have semi-automated meeting note creation we could borrrow
    - conda-forge example
      - GH (need to request PR opens easy step): https://github.com/conda-forge/conda-forge.github.io/blob/26a21b6f4d196db51256a66bf74594358f55ba83/.github/workflows/meeting-notes.yml
      - Past note PR as example: https://github.com/conda-forge/conda-forge.github.io/pull/1942
      - Link to HackMD org with latest notes up-top: https://hackmd.io/@conda-forge
      - Could tag notes and link to filter: https://hackmd.io/@conda-forge?tags=%5B%22meeting-notes%22%5D
    - conda example
      - GH (automated schedule for opening every 2 weeks): https://github.com/conda-incubator/governance/blob/af415b17c42d7ca8eb997d88034e67dbccdcbeb3/.github/workflows/meeting-notes.yml#L14-L16
  - NR: Keep at least two meetings notes
  - ER: Agree with Norman’s proposal
NR: Quetions for ZEP0001
- Q1. What constitutes a reference implementation?
  - SV: Does zarrita have all the sections? Believe so.
  - SV: Documentation or something to share with the community? Needs work.
    - More a technical proof-of-concept (and generate reference data)
    - Tests can be read by other implementors
    - Didn’t add optimizations.
- Q2. How do we get implementations to implement? (esp. zarr-python)
  - SV: deciding on physical vs. in-person. (and/or ZarrCon?) Suggestions?
  - NR: any necessary prework? (also: remote is fine)
- DB: backwards compatibility?
  - JM: personally would opt for trying to not impact end users, but if a new API emerges, that could be used directly.
  - …performance…
  - JK: not absolute performance, but targeted things that could be fixed
SV: Voting for ZEP1
- JK: Mark the PR as approve
- JK: Alternatively voting systems
  - https://vote.heliosvoting.org
  - https://polys.vote
- JK: emoji reactions on a vote comment 👍🏻 / 👎🏻
  - Note: Can be hard to see who voted after a few votes (summarized)
- JM:
- NR:
  - split discussion from vote (i.e. PR)
  - someone maintain a list that’s complete
- DB:
  - Could have a signatory field in the ZEP or other doc
  - Approvers can put their names in the signatory field
  - Maybe have a disenter field as well?
Meetings
- SV and JM at SciPy 2023: https://cfp.scipy.org/2023/talk/T3NSL8/
- SV in Seattle next week
DB: Where does your samples come from e.g. in bio-imaging?
- In bio-imaging the specification of sampling grid is stored as a transformation - essentially matrix
- What if we normalise the storing of grid as array of data? (which is NetCDF way)
- From Zarr side - would need a codec that supports partial read and have metadata as a matrix
- Because specification of the matrix gets awful and you get metadata describing spatial transformations - whether it could really be data
- JMS: You can store the array but your software also need to know how to work with that newly stored array data