Ome owned implementations charter and roster - #7
Conversation
| - **Key Responsibilities:** | ||
| - Developing and maintaining the [`ome-zarr-py`](https://github.com/ome/ome-zarr-py/) library for reading, writing, and manipulating OME-Zarr files. | ||
| - Developing and maintaining the [`ome-zarr-models-py`](https://github.com/ome-zarr-models/ome-zarr-models-py/) library for validating and working with OME-Zarr metadata models. | ||
| - Developing and maintaining the [`napari-ome-zarr`](https://github.com/ome/napari-ome-zarr/) plugin for visualizing OME-Zarr files in the **napari** image viewer. |
There was a problem hiding this comment.
There's a few other repos we could consider adding here?
- ome-ngff-validator
- omero-zarr-pixel-buffer
- omero-cli-zarr
- ome-zarr.js
- bioNGFF/vizarr/
But commitment for all of these to be "reference implementations" is hard.
There was a problem hiding this comment.
Maybe we open a list of items under that paragraph saying something like these X tools can be considered reference?
There was a problem hiding this comment.
I think we should avoid using "reference implementation" wording loosely, it may cause confusion
| 1. **The NGFF Specification** | ||
| - The **NGFF Specification** defines the standards, formats, and protocols for next-generation bioimaging data. Its governance is outlined in the [NGFF Editorial Board Charter](https://ngff--559.org.readthedocs.build/rfc/10/index.html), which describes the decision-making process for the specification itself. | ||
|
|
||
| 2. **OME-Owned Implementations** |
There was a problem hiding this comment.
The https://www.openmicroscopy.org/governance/projects/ page lists NGFF as
NGFF: RFC process, Format standardization
and makes no mention of "implementations". Maybe that should be updated as part of this PR?
clbarnes
left a comment
clbarnes
left a comment
There was a problem hiding this comment.
The process looks good! Comments are fairly minor; I'd add that I personally have a preference for README.md over Readme.md.
| @@ -0,0 +1,127 @@ | |||
| # Charter for the NGFF Project Implementations | |||
|
|
|||
| ## **Overview** | |||
There was a problem hiding this comment.
I wouldn't bother adding additional formatting markup to a header, just let the renderer figure it out. Exception would be if we wanted to emphasise a specific word within the header.
|
|
||
| ## **Aspiration to Be Reference Implementations** | ||
|
|
||
| The **OME-owned implementations** aspire to serve as **reference implementations** of the **NGFF Specification**. This means that the implementations will work towards supporting every feature laid out by the **core NGFF Specification document**. The **Maintainers** and members of the **Project Steering Committee (PSC)** will meet periodically to review progress, ensure alignment with the **NGFF Specification**, and address any gaps or challenges in achieving this goal. |
There was a problem hiding this comment.
Add the caveat that they are non-normative - i.e. the spec text is the source of truth, divergence is a bug in the software. But problems with the spec which are found in the course of implementation (either in an OME-Owned or external impl) may/should inform changes to the spec.
|
|
||
| --- | ||
|
|
||
| ## **Aspiration to Be Reference Implementations** |
There was a problem hiding this comment.
| ## **Aspiration to Be Reference Implementations** | |
| ## **Aspiration to Completeness** |
I think it would be too much to say that all (or any) of the projects aspire to be, technically, reference implementations.
I think we should just use other words
|
|
||
| ## **Aspiration to Be Reference Implementations** | ||
|
|
||
| The **OME-owned implementations** aspire to serve as **reference implementations** of the **NGFF Specification**. This means that the implementations will work towards supporting every feature laid out by the **core NGFF Specification document**. The **Maintainers** and members of the **Project Steering Committee (PSC)** will meet periodically to review progress, ensure alignment with the **NGFF Specification**, and address any gaps or challenges in achieving this goal. |
There was a problem hiding this comment.
| The **OME-owned implementations** aspire to serve as **reference implementations** of the **NGFF Specification**. This means that the implementations will work towards supporting every feature laid out by the **core NGFF Specification document**. The **Maintainers** and members of the **Project Steering Committee (PSC)** will meet periodically to review progress, ensure alignment with the **NGFF Specification**, and address any gaps or challenges in achieving this goal. | |
| The **OME-owned implementations** aspire to support every feature laid out by the **core NGFF Specification document**. The **Maintainers** and members of the **Project Steering Committee (PSC)** will meet periodically to review progress, ensure alignment with the **NGFF Specification**, and address any gaps or challenges in achieving this goal. |
4 participants
This PR registers NGFF as an ORP, with the distinction that the NGFF specification governance is explicitly not laid out here, but in the editorial process RFC. I define a sub-group under the NGFF ORP, i.e. ome-owned implementations under which there is a team that governs these three repos:
I think we will need to shape this sectioning a bit further at some point (we may need different teams for Java projects, the validator, etc), but I think this is a good place to start.
I have added a section to the charter about how adding projects to the governed repos could work - essentially, owner retain their permissions, but the governance then extends to these projects otherwise, i.e. for stepping down as admin or appointing others in the future. I'm marking this as draft because I am not sure whether all is said and done about this proposal, especially with respect to ome-zarr-models-py.
cc @jburel @joshmoore @will-moore @kevinyamauchi @jni @DragaDoncila @melonora