Charter for OME Bio-Formats

Overview

This document formalizes the governance for the Bio-Formats OME Registered Project (ORP). It is a meritocratic, consensus-based, and self-governing process, akin to the Apache model. The primary goal is to empower developers, streamline the development process, and maintain the project’s stability and continuity while adhering to the overarching principles of the overall OME Project.

Roles and Responsibilities

Users

Users are members of the community who utilize the project. Their contributions, such as providing feedback, reporting bugs, and general evangelism, are essential for the project’s purpose and direction.

Contributors

Contributors are community members who engage directly with the project in concrete ways, such as:

• Proposing, discussing, or reviewing a change to the code, documentation, or specification via a pull request.
• Reporting issues through public channels.
• Assisting with documentation or project infrastructure.
• Supporting new users.

All community members are encouraged to contribute. Contributions should be made in compliance with the OME Project’s Code of Conduct. Guidance on providing feedback, bug reports, and test data is available here. Requirements for code and documentation contributions are described in the OME Project’s code contribution policy and third party contribution policy. We strongly recommend reading these documents and seeking clarification if needed before submitting test data or proposing a code or documentation change.

A list of all code and documentation contributors (as of the most recent release) is maintained on the OME website.

Project Steering Committee (PSC)

The Project Steering Committee (PSC) serves as the governing and administrative body for the individual Registered Project. It is equivalent to the Project Management Committee (PMC) in an Apache-governed project.

• Function: The PSC have administrative rights and make decisions, such as accepting or rejecting pull requests, and managing administrative actions within the project’s repositories (e.g. adding/removing members).
• Authority: The PSC is self-governing and its membership is not overseen by the OME Management Group (OMG).
• Membership is Merit-Based: Any contributor is eligible to join the PSC.
  • Nomination: Existing PSC members must nominate new members. Nominations must be based on clear evidence of sustained, quality contribution to the project. Approval is subject to vote by the existing PSC (ideally consensus, but at minimum majority approval).
  • Removal: PSC members who become inactive can and should be removed via a majority vote of the existing active PSC.

The PSC is currently defined as anyone with a Maintainer role as defined in the Bio-Formats roster.

PSC Chair

The Chair’s role is to act as a coordinator and facilitator for the group’s activities and discussions. The Chair holds no additional authority over other PSC members.

The current Chair is Melissa Linkert (Glencoe Software). The Chair role may be temporarily passed to anyone else on the PSC due to extended absence, by agreement within the PSC. Permanent changes may be made by agreement within the PSC, or, if that is not possible, directive from the OMG.

Decision Making Process

Decisions should be made in accordance with the mission and values of the OME Project. Decisions are primarily made through consensus-seeking as described below, and are discussed as publicly as possible. Given the foundational nature of the Bio-Formats project, decisions may impact other ORPs (in particular, Core Model, NGFF, and OMERO server). When making decisions that impact other ORPs, all reasonable effort should be made to work with the PSC and/or maintainers of those ORPs to reach a mutually agreeable decision.

Consensus-Seeking and Voting

The project aims for consensus among PSC members for all decisions. If consensus cannot be reached after discussion, decisions will be resolved by falling back on a majority vote of the PSC.

Discussions primarily occur:

• publicly, in GitHub pull requests and issues
• semi-publicly, in OME project-wide meetings which are publicly minuted
• semi-privately, in dedicated weekly meetings which span the Core Model, Bio-Formats and NGFF ORPs with minutes accessible to members of the OME Project
• privately, via Slack or ad hoc meetings as needed

Preference is given to public discussion. In the case of private and semi-private discussions, a summary of discussion and outcome is to be shared publicly.

Lazy Consensus for Day-to-Day Operations

Lazy Consensus is used for most day-to-day decisions, allowing the majority of contributions to proceed efficiently.

• Minor Documentation Changes (e.g. typo fixes): Require approval by a Core Developer and no disagreement or requested changes from any Core Developer within a reasonable time (e.g. one working day).
• Code Changes and Major Documentation Changes: Require agreement by one Core Developer and no disagreement or requested changes from any Core Developer within a reasonable time (e.g. a few working days).
• Objections: If a Core Developer raises an objection to a proposal under lazy consensus, the proposal is escalated to the full group for a consensus-seeking discussion or a majority vote.

A Core Developer or Maintainer may request additional reviews from individuals with other roles, and in some cases from community members who are not currently listed on an ORP roster. These reviews should be taken seriously (if submitted), and all reasonable attempts should be made to resolve disagreements between reviewers with any role. However, it is ultimately up to an agreement within the PSC whether a requested change or the absence of a review blocks a proposed change.

Repositories and Other Resources

GitHub Repositories

Code and documentation in the scope of the Bio-Formats project are divided into the following public repositories within the ome organization:

• https://github.com/ome/bioformats
• https://github.com/ome/bio-formats-documentation
• https://github.com/ome/bio-formats-examples
• https://github.com/ome/ome-codecs
• https://github.com/ome/ome-common-java
• https://github.com/ome/ome-jai
• https://github.com/ome/ome-mdbtools
• https://github.com/ome/ome-metakit
• https://github.com/ome/ome-poi
• https://github.com/ome/ome-stubs

Test Data

As described in OME’s third party data usage policy, OME maintains a repository of data that is used to test changes to Bio-Formats on a nightly basis. Much of this repository is only accessible to members of the OME project, due to licensing concerns.

For each test dataset, there is a corresponding configuration entry in the private data_repo_config repository. This repository is also restricted to members of the OME project. Configuration data is used to ensure that changes to Bio-Formats do not unexpectedly alter how existing data is read, as described in Bio-Formats’ testing documentation.

Nightly test builds are run on infrastructure that is accessible to individuals with a Maintainer role. The nightly build process is documented together with relevant scripts, and is accessible to all members of the OME project. Results of nightly tests are publicly reported via GitHub Action on the bioformats repository.

Release Processes

The process for a full Bio-Formats release is documented on the Bio-Formats release page. Similarly, the process for releasing individual components (e.g. ome-common-java) is documented on the Java component release page. These pages are updated as needed via pull requests to the ome-contributing repository.

Code of Conduct

As a Registered Project, Bio-Formats adheres to the OME Project’s Code of Conduct. The Bio-Formats project and prospective contributors are expected to adhere to OME’s third party contribution and communication policy.

License and Attribution

This governance document is adapted from the original Zarr governance document and the Meritocratic governance model by Ross Gardler and Gabriel Hanganu (licensed under a Creative Commons Attribution-ShareAlike 4.0 International License).