Skip to content

ZEP-11 Governance Updates #52

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.

Sign up for GitHub

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

Open
rabernat wants to merge 1 commit into
base: main
Choose a base branch
from
Open

ZEP-11 Governance Updates #52

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 106 additions & 0 deletions AFFILIATED_PROJECT_GOVERNANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
# Governance for Zarr Affiliated Software Projects

## Overview

This document formalizes the default governance for an individual Zarr
Affiliated Software Project. 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 Zarr
Project framework as a NumFocus-sponsored entity.

Projects are encouraged to start with this template and adapt it to their
needs. Projects may deviate from this template for good reasons; we suggest
starting here and evolving as the project matures.

## 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 a GitHub issue.
* Assisting with documentation or project infrastructure.
* Supporting new users.

All community members are encouraged to contribute. Contributions should be
made in compliance with the Zarr Project's
[Code of Conduct](https://github.com/zarr-developers/.github/blob/main/CODE_OF_CONDUCT.md).

### Core Developers

The Core Developers Group (CDG) serves as the governing and administrative
body for the individual Affiliated Software Project. It is equivalent to
the Project Committee in an Apache-governed project.

* **Function:** The Core Developers 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). A group of one is acceptable for small projects.
* **Authority:** The Core Developers Group is **self-governing** and its
membership is **not overseen by the Zarr Steering Council (ZSC)**.
* **Membership is Merit-Based:** Any contributor is eligible to join the
Core Developers.
* **Nomination:** Existing Core Developers can 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 Core Developers (ideally consensus, but at minimum **majority
approval**).
* **Removal:** Core Developers who become inactive can and should be
removed via a **majority vote** of the existing Core Developers.

### Core Developers Chair

Larger projects should have a 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 Core Developers. The
Chair is optional for smaller projects.

## Decision Making Process

Decisions should be made in accordance with the mission and values of the
Zarr Project.

### Consensus-Seeking and Voting

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

### 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.

## Code of Conduct

All Affiliated Software Projects must adhere to the Zarr Project's
[Code of Conduct](https://github.com/zarr-developers/.github/blob/main/CODE_OF_CONDUCT.md),
which is a requirement for NumFocus fiscal sponsorship.

## License and Attribution

This governance document is adapted from the original Zarr governance
document and the
[Meritocratic governance model](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
by Ross Gardler and Gabriel Hanganu (licensed under a Creative Commons
Attribution-ShareAlike 4.0 International License).
54 changes: 28 additions & 26 deletions CORE_DEV_GUIDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,13 +1,16 @@
# Core Developer Guide

Welcome, new core developer! The core team appreciate the quality of
Welcome, new core developer! The core team appreciate the quality of
your work, and enjoy working with you; we have therefore invited you
to join us. Thank you for your numerous contributions to the project
to join us. Thank you for your numerous contributions to the project
so far.

You can see a list of all the current core developers on our
[@zarr-developers/core-devs](https://github.com/orgs/zarr-developers/teams/core-devs)
GitHub team. You should now be on that list too.
Each Affiliated Software Project maintains its own Core Developers Group.
You should now be on the GitHub team for the project you've been invited to.
See [GOVERNANCE.md](GOVERNANCE.md) for how the Core Developers Group fits
into the overall Zarr governance framework, and
[AFFILIATED_PROJECT_GOVERNANCE.md](AFFILIATED_PROJECT_GOVERNANCE.md) for
the default governance template for Affiliated Software Projects.

This document offers guidelines for your new role.
As a core team member, you gain the responsibility of shepherding
Expand Down Expand Up @@ -156,31 +159,30 @@ sparingly for discussions that are required to be private, such as voting on new

## Inviting New Core Members

Any core member may nominate other contributors to join the core team.
While there is no hard-and-fast rule about who can be nominated, ideally,
they should have: been part of the project for at least two months, contributed
significant changes of their own, contributed to the discussion and
review of others' work, and collaborated in a way befitting our
community values.
Any core member may nominate other contributors to join their project's
Core Developers Group. While there is no hard-and-fast rule about who can
be nominated, ideally, they should have: been part of the project for at
least two months, contributed significant changes of their own, contributed
to the discussion and review of others' work, and collaborated in a way
befitting our community values.

To make a nomination, email the private Zarr developer mailing list
with the name and GitHub handle of who you wish to nominate. All developers
should then vote on whether to accept or reject the nomination, with a voting
period of three weeks. While it is expected that most votes will be unanimous,
a majority of the cast votes is enough.

After three weeks has elapsed, if the majority of cast votes is in favour,
the current developer who made the nomination should email the succesful nominee
thanking them for their contributions so far, and asking if they would like to join the team.
Nominations must be based on evidence of sustained, quality contribution
to the project. The specific nomination and voting process is determined
by each project's governance document. The default process (see
[AFFILIATED_PROJECT_GOVERNANCE.md](AFFILIATED_PROJECT_GOVERNANCE.md)) calls
for approval by majority vote of existing Core Developers, with consensus
preferred.

## Offboarding Core Members

Core developers are expected to regularly participate in the project. Participation is defined
as any of the following activities: contributions to the project's source code or documentation,
engagement in discussions on the project's issue tracker, code reviews, and user support. Core
developers may choose to become emeritus core developers and suspend their approval and voting rights
until they become active again. If a core developer becomes inactive in the project for a period of
one year, they may be removed or classified as emeritus by the core developer team with a majority vote.
Core developers are expected to regularly participate in the project.
Participation is defined as any of the following activities: contributions
to the project's source code or documentation, engagement in discussions on
the project's issue tracker, code reviews, and user support. Core developers
may choose to become emeritus core developers and suspend their approval and
voting rights until they become active again. If a core developer becomes
inactive in the project for a period of one year, they may be removed or
classified as emeritus by the Core Developers Group with a majority vote.

## Contribute To This Guide!

Expand Down
Loading