Skip to content

GOVERNANCE.md

Latest commit

 

History

History
76 lines (50 loc) · 3.4 KB

GOVERNANCE.md

File metadata and controls

76 lines (50 loc) · 3.4 KB

Governance

Overview

GoSQLX is an open source project. This document describes how the project is governed, how decisions are made, and how contributors can take on more responsibility over time.

Roles

Users

Anyone who uses GoSQLX. Users are the most important people in the project - feedback through issues, questions in Discussions, and bug reports directly shapes development priorities.

Contributors

Anyone who has submitted a merged pull request, a bug report that led to a fix, or substantive documentation improvements. Contributors are credited in release notes and the CHANGELOG.

Committers

Contributors who have demonstrated sustained, high-quality contributions across multiple areas of the codebase. Committers can:

  • Merge pull requests after review
  • Triage and label issues
  • Cut release branches

Current committers: @ajitpratap0

To become a committer: contribute consistently for at least 3 months, demonstrate understanding of the architecture, and express interest in a GitHub Discussion or issue.

Maintainers

Responsible for the overall technical direction, release management, and final decisions on breaking changes. Maintainers are committers who have committed to long-term stewardship.

Current maintainer: @ajitpratap0

Decision Making

Everyday decisions (bug fixes, docs, minor features)

Open a PR. If CI passes and a committer reviews it positively, it can be merged. No formal vote needed.

Significant features (new AST nodes, new dialect support, new packages)

  1. Open an issue tagged feature with a design proposal (what, why, API sketch)
  2. Allow 5 business days for community feedback
  3. A committer signals approval (thumbs-up, "LGTM" comment, or review approval)
  4. Proceed with implementation PR

Breaking changes

  1. Open an issue tagged breaking-change - mandatory minimum 14-day comment period
  2. Document the migration path in docs/MIGRATION.md before merge
  3. Requires explicit maintainer approval
  4. Semantic versioning: breaking changes increment the minor version (v1.x.0)

Governance changes

Changes to this document require a GitHub Discussion open for at least 7 days with no unresolved objections.

Release Process

GoSQLX follows Semantic Versioning:

  • Patch (v1.9.x): bug fixes, security patches, documentation - no API changes
  • Minor (v1.x.0): new features, new dialect support, new AST nodes - backward compatible
  • Major (vX.0.0): breaking API changes - rare, requires 14-day notice

Release cadence: ad-hoc driven by feature readiness and bug severity, roughly monthly.

Releases are tagged on main and built automatically by GoReleaser. See CONTRIBUTING.md for the tagging workflow.

Conflict Resolution

Disagreements on technical direction are resolved by:

  1. Discussion in the relevant issue/PR (preferred)
  2. A GitHub Discussion for broader input
  3. Maintainer decision as a tiebreaker

The goal is always rough consensus - not unanimity, but no strong unaddressed objections.

Code of Conduct

All participants are expected to follow our Code of Conduct.

Acknowledgements

This governance model is inspired by the Node.js and Go project governance models, simplified for a single-maintainer open source library.