Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preparation for core protocol v3 first public working draft and RFC #101

Closed
alimanfoo opened this issue Oct 21, 2020 · 3 comments
Closed
Labels

Comments

@alimanfoo
Copy link
Member

This issue is intended for planning and coordination towards publishing a First Public Working Draft of the Zarr core protocol v3 specification and issuing a public request for comments (RFC).

We discussed this on today's community call, we suggested to aim for publishing the spec and issuing the RFC on Wednesday 4 November.

Suggested plan

  • Ask Zarr core devs to read through the current editor's draft and raise any issues they think need to be addressed before we can issue an RFC. N.B., the spec doesn't have to be perfect before RFC, so the goal here is just to deal with any obvious mistakes, inconsistencies, potential confusions, major gaps etc.
  • Spec editors (@Carreau, @alimanfoo) resolve any issues raised above.
  • Spec editors make a final PR to change the document type from "Editor's Draft" to "First Public Working Draft" and merge into the master branch on the zarr-specs repo.
  • Update the RTFD config for zarr-specs.readthedocs.io to serve from the master branch (currently serving from dev branch).
  • Write a blog post for the zarr blog declaring the spec is published, announcing the RFC, and providing any other useful information like motivation for this spec, pointers to current implementation work, plan for future timeline, etc.
  • Publicize the RFC via Twitter (@zarr_dev, ...) and other channels

Notes

  • The plan is to ask for comments to be submitted by raising issues on the zarr-specs repo.
  • It's suggested we follow a convention similar to W3C where they label a spec as "Editor's Draft" if it is an internal draft only intended for consumption within the group of people actively working on it, then will publish a "Working Draft" when the document has reached some maturity and they want to make it public and request comments from outside the core team. Here "Working Draft" indicates the documents maturity level. They will also add a date, e.g., "First Public Working Draft 21 October 2020", which then allows for publication of a second working draft if necessary.
  • Following on from this, it's suggested that we reserve the master branch on the zarr-specs repo for specs that are intended to be public, i.e., have a "Working Draft" maturity level or beyond.
  • At some point we should capture and document these conventions around process and document maturity levels.
@alimanfoo
Copy link
Member Author

Hi @zarr-developers/core-devs, @davidbrochart, I'd be very grateful if you could let me know if the plan outlined above sounds good, or if you have any other suggestions.

Also if you had any time to take a pass over the current editor's draft of the core protocol v3 spec some time in the next week I'd be very grateful if you could raise any issues that you think would need to be addressed before we could publish this document as a public working draft and ask for comments.

Many thanks 🙏

@rabernat
Copy link
Contributor

The v2 spec is currently working its way through the OGC "community standard" process. I was wondering if we wanted to consider involving the OGC community in the v3 RFC process.

Are there equivalent standards organizations in bioinformatics / bioimaging we could be working with here?

@jstriebel
Copy link
Member

We're following the ZEP process now, (see ZEP 0), and just posted an update on the next steps: https://zarr.dev/blog/zep1-update.

The OGC proposal is tracked separately in issue #42, closing this issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

No branches or pull requests

3 participants