Skip to content

GOVERNANCE.md

Latest commit

 

History

History
44 lines (29 loc) · 2.64 KB

GOVERNANCE.md

File metadata and controls

44 lines (29 loc) · 2.64 KB

Governance

Goals

LibreFang — "libre" as in freedom — exists to maintain the codebase as a truly open community project. We accept outside contributions through normal GitHub workflows, preserve contributor credit, and actively help contributors get their work merged.

Core Principle: Merge-First

If a contribution positively helps the project, we merge it. This is the default, not the exception.

  • PRs that meet quality standards are merged as-is with full contributor attribution.
  • PRs that need improvement receive active, constructive code review with specific suggestions — we help contributors ship their work, not block it.
  • We do not silently close PRs or let them go stale without explanation.

Decision-Making

  • Day-to-day technical decisions are made in pull requests and issues — not behind closed doors.
  • Maintainers are expected to explain design rejections with concrete technical reasons.
  • Breaking governance changes should be proposed in a pull request against this file.

Contribution Policy

  • Accepted changes land through GitHub merge or squash merge.
  • If a maintainer needs to adapt or rewrite a contributor's patch, the maintainer preserves attribution with commit metadata such as Co-authored-by and credits the contributor in release notes.
  • Closing a pull request and re-implementing it privately without attribution is explicitly prohibited.
  • Large design changes should start as an issue so contributors can align before doing heavy implementation work.
  • All types of contributions are valued equally: code, documentation, tests, translations, packaging, issue triage, and community support.
  • Active contributors are invited to join the LibreFang GitHub organization. Core participants who demonstrate sustained, quality contributions are granted commit access and a voice in project governance.

Review Expectations

  • New pull requests receive an initial maintainer response within 7 days.
  • If a pull request is blocked on architecture or scope, maintainers say so explicitly and suggest a path forward.
  • Stale pull requests may be closed after explanation, but contributors are always told the reason and how to revive the work.

Maintainers

  • Repository maintainers are responsible for review quality, release management, and enforcing this governance document.
  • Maintainers should avoid becoming a single-person bottleneck. When possible, at least two people should be able to review and release the project.
  • Maintainer expectations and the current roster are tracked in MAINTAINERS.md.

Security

Security reports use the private process in SECURITY.md, not public issues.