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 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.
The text was updated successfully, but these errors were encountered:
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.
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?
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
Notes
The text was updated successfully, but these errors were encountered: