Skip to content

Create GOVERNANCE.md #402

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

Merged
merged 8 commits into from
Apr 22, 2024
Merged
Changes from all commits
Commits
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
120 changes: 120 additions & 0 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,120 @@
# fastplotlib governance

The governance of fastplotlib applies to all fastplotlib related activities. This includes the fastplotlib GitHub organization, all repositories under the fastplotlib GitHub organization, as well as any events or workshops organized by members of the fastplotlib Leadership Team.

The purpose of this document is to formalize the governance process used by the fastplotlib project, to clarify how decisions are made and how the various elements of our community interact.

## Mission

The mission of `fastplotlib` is to leverage new graphics APIs and modern GPU hardware to create fast and interactive scientific visualizations using an expressive and elegant API.

`fastplotlib` aims to provide a library that allows for the following:
- Rapid prototyping and algorithm development
- Realtime analysis and visualization
- Efficient rendering of thousands of objects
- Compatibility with lazy-loading and lazy-compute objects
- Shipping dependent packages as a distributable (ex: PyInstaller)

Ultimately, `fastplotlib` is, and will always be, a free and open-source project that belongs to the community. Our end goal is to aid in the advancement of science, and as a result, we will guide the project in a direction that best serves our community in achieving this purpose.

## Leadership Team

### Maintainers

The maintainers are the core developers of fastplotlib and together have a complete understanding of the codebase. They are also known as code-owners. At any given time, there must be a minimum of two maintainers.

The current maintainers are:

1. [Kushal Kolar](https://github.com/kushalkolar)
1. [Caitlin Lewis](https://github.com/clewis7)

Responsibilities:

* Carry out the `fastplotlib` mission.
* Work towards completion of the roadmap.
* Timely responses to issues and pull requests.
* Code review.
* Attend a yearly Roadmap meeting.
* Be available for conflict resolution.

### Advisory Committee

The Advisory Committee holds a significant interest in fastplotlib as determined solely by the **Maintainers**.

1. Amol Pasarkar
1. Eric Thomson
1. Andrea Giovannucci
1. John Pearson

Responsibilities:

* Help carry out the `fastplotlib` mission.
* Provide strategic guidance.
* Attend a yearly Roadmap meeting.
* Be available for conflict resolution.

### Neutral moderator

No voting power, has no stake in the fastplotlib project.

* Reagan Bullins

Responsibilities:

* Facilitate conflict resolution without voting power.

## Adding a member to the advisory committee
1. Only individuals, not organizations, may be added to the leadership team. A candidate individual must be nominated by a current member of the leadership team.
2. A candidate must:
* Be committed to the fastplotlib mission.
* Have demonstrated contibutions to `fastplotlib` through one of:
* Significant contributions to the codebase.
* Significant application of fastplotlib in a dependent package.
* Significant technical guidance or feedback on the development of `fastplotlib`.

## Adding a maintainer

Candidate maintainers must have demonstrated prolonged and significant contributions to the codebase over a long period of time. A candidate can be nominated by any current maintainer. The candidate may then be added as a maintainer through a unanimous vote within the current maintainers.

## Decision making

Decisions about the future of the project are made through discussion with all members of the community. All non-sensitive project management discussion takes place on the issue tracker. Occasionally, sensitive discussions may occur on a private core developer medium.

Decisions should be made in accordance with the mission and code of conduct of the `fastplotlib` project.

We use a “consensus seeking” process for making decisions. The Leadership Team tries to find a resolution that has no open objections among Leadership Team members. Leadership Team members are expected to distinguish between fundamental objections to a proposal and minor perceived flaws that they can live with, and not hold up the decision-making process for the latter. If no option can be found without objections, the decision is escalated to the maintainers who have ultimate authority.

Decisions are made according to the following rules:

Minor documentation changes, such as typo fixes, or addition / correction of a sentence, require approval by a maintainer and no disagreement or requested changes by other maintainers on the issue or pull request page via lazy consensus. Pull-request authors are expected to give “reasonable time” to others to give their opinion on the pull request if they’re not confident others would agree.

Code changes and major documentation changes require agreement by one maintainer and no disagreement or requested changes by other maintainers on the issue or pull-request page (lazy consensus). For all changes of this type, maintainers are expected to give “reasonable time” after approval and before merging for others to weigh in on the pull request in its final state.

Changes to the API principles require a dedicated issue on our issue tracker and follow the decision-making process outlined above.

Changes to this governance model or our mission, vision, and values require a dedicated issue on our issue tracker and follow the decision-making process outlined above.

If an objection is raised on a lazy consensus, the proposer can appeal to the Leadership Team and the change can be approved or rejected by escalating to the maintainers.

## Conflict Resolution

Anyone (absolutely anyone, not just the leadership team members) who feels that the code of conduct or governance document has been breached may invoke a vote by contacting the neutral moderator.

### Process

1. Contact the neutral moderator with a description of the conflict, max of 250 words.
2. Neutral moderator must schedule a vote within 15 days. If that is not possible then within the next 45 days.
3. The individual who has invoked the conflict vote can choose to present their case, or they may choose to let the neutral moderator represent them.
* Every individual involved in the conflict is given a maximum of 15 minutes to be represented. This time limit may be expanded at the discretion of the neutral moderator if a justifiable reason is provided.
4. The maintainers vote on one of the actions from “Enforcement Guidelines”: https://www.contributor-covenant.org/version/2/1/code_of_conduct/. It is advised that the first offense leads to action (1) “Correction”. Repeated or serious offenses from the same individual/organization may lead to escalating levels of actions. Very bad behavior, as determined by the leadership team, can justify a first offense resulting in (3) “Temporary Ban” or (4) “Permanent Ban”.
5. The advisory committee members may advise on the actions, but the ultimate decision is voted on by the maintainers.

## Transparency

Governance decisions, meeting minutes, and voting outcomes are publicly documented and accessible. We aim for transparency to allow the broader community to understand and trust the governance process.

## Changes to this governance document

### Until February 28, 2025

During early stages of fastplotlib development, changes to the governance document may be made directly through unanimous approval by the original maintainers, Kushal Kolar & Caitlin Lewis. They (Kushal & Caitlin) may also add new members to the advisory committee through unanimous approval.
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy