Announcing: Draft Docsy Governance

[emckean]

Goal: to have a lightweight, sustainable process for decision-making in the Docsy project.

Next steps: Please read and leave comments on this discussion! We look forward to your comments. We plan to put this governance in place in early 2022.

Roles

Project Steering Committee

• The PSC is a group of 3-7 people
• Responsibilities/Duties
  • Maintain the project roadmap
  • Resolve questions about direction of the project
  • PSC members are usually committers but do not have to be
  • A subset of the PSC handles Code of Conduct violations
• Terms
  • PSC members should serve no longer than 18 months; after a break of at least a quarter, can rejoin PSC
  • At every vacancy, PSC votes on all nominated people
    • Voting will be weighted: each PSC member gets three votes and can vote for up to 3 different candidates, top vote-getter(s) are then on PSC
• Qualifications
  • Anyone with a history of participation in the project or related projects (such as Hugo) can be nominated to the PSC
  • Nominees should have no unresolved Code of Conduct issues
• Privileges
  • PSC members participate in in the roadmap meetings

Committers

• Responsibilities:
  • Committers review and merge pull requests
    • Non-committers can review PRs if necessary/appropriate; in that case committers review that review and approve/merge the PR
• Any number of people can be granted commit access to the docsy.dev or docsy-example repos, but in practice should be <10
• Anyone can be nominated as a committer, PSC will vote at each meeting to nominate and add new committers
  • Committers should have demonstrated sufficient knowledge of Docsy topics: through making PRs that were accepted, by writing technical articles about Docsy/Hugo, through performing or writing tests, raising substantiated and useful issues in the project, reproducing bugs, moderating community discussions, or otherwise contributing to the health and sustainability of the project.
• PSC should review list of committers quarterly and “snooze” any committers who have not made any commits or reviewed/merged any PRs or issues in the last two quarters
  • Snoozed committers can reactivate by asking the PSC
• Committers must agree to make sure Google’s CLA check (and any other required checks) pass before merging any pull requests
• Committers should not merge their own PRs

Roadmap Process

• Once a quarter, the PSC meets to review roadmap requests (issues tagged #roadmap in the docsy and docsy-example repositories)
• All roadmap requests should be reviewed against the Docsy project roadmap principles:
  • Roadmap priorities are:
    • Keeping up with Hugo, Bootstrap, and other dependencies
    • Minimize breaking changes (especially those that would affect bigger Docsy sites)
    • Bugfixes
    • User feature/improvements requests
    • General improvements
  • Requests that come with an offer of help or solutions are more likely to be added to the roadmap
  • Requests that have good documentation (problem statement, possible solutions, possible risks) are more likely to be added to the roadmap
  • All new features must be documented before merge
  • Features that provide flexibility or functionality through configuration are preferred over those replacing defaults
  • Features that integrate with commercial services should offer the option of a free plan (free plans for OSS qualify as free plans)
• Roadmap will be published to https://github.com/google/docsy/projects/2