Skip to content

GOVERNANCE.md

Latest commit

 

History

History
276 lines (183 loc) · 8.11 KB

GOVERNANCE.md

File metadata and controls

276 lines (183 loc) · 8.11 KB

Governance

This document describes the governance model for the Promethium project, including roles, responsibilities, decision-making processes, and contribution pathways.

Table of Contents

Project Vision

Promethium aims to be the leading open-source framework for AI-driven seismic data recovery and reconstruction. The project serves both academic research and industry applications, maintaining a balance between innovation and production stability.

Core Values

  • Scientific Rigor: Implementations are grounded in established geophysical principles.
  • Technical Excellence: Code quality, testing, and documentation meet professional standards.
  • Open Collaboration: Development is transparent and welcomes diverse contributions.
  • User Focus: Features and improvements are driven by real-world use cases.

Governance Principles

Transparency

  • All technical decisions are made in public forums (GitHub issues, discussions, pull requests).
  • Roadmap and priorities are documented and publicly accessible.
  • Meeting notes and significant discussions are summarized publicly.

Meritocracy

  • Contributions are valued based on quality and impact.
  • Advancement in roles is based on demonstrated expertise and commitment.
  • Technical decisions are based on merit, not authority.

Consensus-Seeking

  • Major decisions seek broad agreement among stakeholders.
  • Disagreements are resolved through discussion and compromise.
  • When consensus cannot be reached, maintainers make final decisions.

Inclusivity

  • The project welcomes contributors from all backgrounds.
  • Multiple expertise areas are valued: geophysics, ML, software engineering, documentation.
  • Barriers to participation are actively identified and reduced.

Roles and Responsibilities

Users

Users consume the project without contributing code or documentation.

Expectations:

  • Follow the Code of Conduct.
  • Report bugs through appropriate channels.
  • Provide feedback on usability and features.

Contributors

Contributors have made at least one accepted contribution to the project.

Types of Contributions:

  • Code (features, bug fixes, tests)
  • Documentation
  • Issue triage and reproduction
  • Community support
  • Translations

Recognition:

  • Listed in contributor acknowledgments.
  • May participate in project discussions.

Committers

Committers have demonstrated sustained, quality contributions and are granted write access to the repository.

Responsibilities:

  • Review and merge pull requests.
  • Maintain code quality standards.
  • Support and mentor contributors.
  • Participate in technical discussions.

Requirements:

  • History of quality contributions.
  • Familiarity with project conventions.
  • Nomination by existing committer or maintainer.
  • Approval by maintainers.

Maintainers

Maintainers have overall responsibility for the project direction and health.

Responsibilities:

  • Set project vision and roadmap.
  • Make final decisions on contentious issues.
  • Manage releases.
  • Handle security issues.
  • Ensure project sustainability.
  • Add or remove committers.
  • Represent the project externally.

Current Maintainers:

Name Focus Area GitHub
Olaf Yunus Laitinen Project Lead, Architecture @olaflaitinen

Technical Steering Committee (Future)

As the project grows, a Technical Steering Committee (TSC) may be established to share governance responsibilities. The TSC would:

  • Consist of 3-5 maintainers.
  • Make decisions by majority vote.
  • Meet regularly to discuss project direction.
  • Rotate responsibilities among members.

Decision-Making Process

Standard Decisions

Standard decisions (routine bug fixes, documentation updates, minor features) follow this process:

  1. Contributor opens a pull request.
  2. One or more committers review the change.
  3. If approved, any committer may merge.
  4. If concerns arise, discussion continues until resolved.

Significant Decisions

Significant decisions (major features, architecture changes, API modifications) require:

  1. Proposal in a GitHub issue or discussion.
  2. Minimum 7-day comment period.
  3. Review by at least two maintainers or committers.
  4. Explicit approval before implementation.

Breaking Changes

Breaking changes require:

  1. Detailed proposal with migration path.
  2. Minimum 14-day community feedback period.
  3. Documentation of breaking changes and upgrade instructions.
  4. Maintainer approval.

Voting

When consensus cannot be reached:

  1. Maintainers may call for a vote.
  2. Each maintainer has one vote.
  3. Simple majority decides.
  4. In case of tie, the project lead has tie-breaking authority.

Contribution Ladder

Path to Committer

  1. Contribute regularly: Multiple accepted contributions over several months.
  2. Demonstrate expertise: Show understanding of codebase and conventions.
  3. Engage constructively: Participate helpfully in discussions and reviews.
  4. Be nominated: Existing committer or maintainer proposes you.
  5. Maintainer approval: Maintainers vote on nomination.

Path to Maintainer

  1. Serve as committer: Sustained contributions as a committer.
  2. Show leadership: Take initiative on significant features or areas.
  3. Mentor others: Help grow the contributor community.
  4. Demonstrate judgment: Make sound technical and community decisions.
  5. Maintainer invitation: Existing maintainers invite you to join.

Stepping Down

Contributors may step down from roles at any time by notifying maintainers. Stepping down gracefully includes:

  • Completing or handing off in-progress work.
  • Documenting any specialized knowledge.
  • Training successors if possible.

Inactive committers may have their access adjusted after 12 months of inactivity, with prior notification.

Maintainer Selection

Adding Maintainers

New maintainers are selected when:

  1. Project growth requires additional leadership.
  2. A committer demonstrates sustained maintainer-level contribution.
  3. Existing maintainers unanimously agree on the addition.

Removing Maintainers

A maintainer may be removed for:

  • Voluntary resignation.
  • Extended inactivity (12+ months with no response).
  • Code of Conduct violations.
  • Loss of trust by other maintainers.

Removal requires:

  • Documented concerns shared with the maintainer.
  • Opportunity for the maintainer to respond.
  • Vote by remaining maintainers.

Conflict Resolution

Technical Disputes

  1. Discuss in the relevant GitHub issue or pull request.
  2. If unresolved, escalate to maintainers.
  3. Maintainers facilitate discussion and seek consensus.
  4. If needed, maintainers make a final decision.

Interpersonal Conflicts

  1. Attempt direct resolution between parties.
  2. If unresolved, report to maintainers.
  3. Maintainers mediate following Code of Conduct procedures.
  4. Enforcement actions are applied if necessary.

Appeals

Decisions may be appealed by:

  1. Opening a governance issue with clear rationale.
  2. Maintainers review the appeal.
  3. The decision may be upheld, modified, or reversed.

Changes to Governance

This governance document may be amended through:

  1. Proposal via pull request to this file.
  2. Minimum 14-day community review period.
  3. Discussion and revision based on feedback.
  4. Unanimous approval by maintainers.

Minor clarifications may be made with standard pull request review.

Contact

For governance-related questions not addressed here, contact the maintainers through:

  • GitHub Discussions
  • Project communication channels listed in SUPPORT.md

This governance document is inspired by governance models from established open-source projects including the Linux Foundation, Apache Software Foundation, and CNCF projects.