From 7617ab93006d0a67321176be8240d0f8e068f4e2 Mon Sep 17 00:00:00 2001 From: mrizzi Date: Tue, 7 Jul 2026 09:33:37 +0200 Subject: [PATCH] docs: add CONTRIBUTING.md with contributors ladder Define four-tier contributors ladder (Contributor/Reviewer/Maintainer/Owner) mapped to GitHub repository roles, promotion criteria with hybrid model, demotion policy, issue/PR workflows, and branch protection rules. Implements TC-5079 Assisted-by: Claude Code --- CONTRIBUTING.md | 103 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..9ce88437 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,103 @@ +# Contributing to sdlc-plugins + +Thank you for your interest in contributing! This document describes our +contributors ladder, governance policies, and workflows for issues and pull +requests. + +## Contributors Ladder + +This project uses a four-tier contributors ladder mapped to GitHub repository +roles: + +| Tier | GitHub Role | Capabilities | +|------|-------------|--------------| +| Contributor | Read | File issues, submit PRs, participate in discussions | +| Reviewer | Write | All Contributor capabilities, plus: review and approve PRs, push to non-protected branches, triage issues | +| Maintainer | Maintain | All Reviewer capabilities, plus: merge PRs, manage releases, configure branch protection, maintain CI | +| Owner | Admin | All Maintainer capabilities, plus: manage repository settings, grant/revoke roles, make governance decisions | + +## Current Contributors + +| Name | Tier | +|------|------| +| mrizzi | Owner | +| ruromero | Maintainer | +| mrrajan | Contributor | + +## Promotion Criteria + +Promotions follow a hybrid model: approximately three months of sustained, +quality contributions combined with maintainer judgment. Mechanical tenure alone +is not sufficient — the quality, scope, and consistency of contributions matter +more than the calendar. + +### Tier Transitions + +| Transition | Who Nominates | Who Approves | +|------------|---------------|--------------| +| Contributor to Reviewer | Any Maintainer or Owner | One other Maintainer or Owner (not the nominator) | +| Reviewer to Maintainer | Any Owner | Another Owner (not the nominator) | +| Maintainer to Owner | Existing Owners | Consensus among all existing Owners | + +Nominations are made by opening a discussion in the repository. The nominee +should be given the opportunity to accept or decline before any role change is +applied. + +## Demotion Policy + +Contributors who have been inactive for approximately one year may have their +role adjusted. Before any role change: + +1. A Maintainer or Owner reaches out privately to the contributor to understand + their situation and intentions. +2. The contributor is given a reasonable opportunity to respond. +3. Only after this private conversation may a role change be proposed. + +Role changes due to inactivity are not punitive — contributors are welcome to +re-engage at any time and work toward re-promotion through the normal promotion +criteria. + +## Reporting Issues + +### External contributors + +[GitHub Issues](../../issues) are the entry point for external contributors. +Use the available issue templates: + +- **Bug report** — describe unexpected behavior with steps to reproduce +- **Feature request** — propose new functionality or improvements + +### Internal team members + +Internal team members are welcome to create issues directly in the project's +Jira board. Link the Jira issue to a GitHub Issue when external visibility is +needed. + +## Submitting Pull Requests + +This project uses a fork-and-PR model: + +1. **Fork** the repository to your own GitHub account. +2. **Create a branch** in your fork for the change. +3. **Reference the GitHub Issue** in your PR description (e.g., + `Closes #42`). If no issue exists, consider creating one first. +4. **Follow Conventional Commits** for commit messages (e.g., + `feat(plan-feature): add validation step`). See + [CONVENTIONS.md](CONVENTIONS.md) for the full commit message format. +5. **Open a pull request** against the `main` branch of this repository. +6. **Address review feedback** — at least one Reviewer (Write role or above) + must approve the PR before it can be merged. +7. **Merging** — Maintainers or Owners merge approved PRs. + +## Branch Protection + +The `main` branch is protected with the following rules: + +- **Pull request reviews required** — direct pushes to `main` are not allowed; + all changes must go through a reviewed pull request. +- **Passing CI required** — the CI pipeline must pass before a PR can be merged. +- **At least one approval from a Write-level or above contributor** — a + Reviewer, Maintainer, or Owner must approve the PR. + +> **Note:** Applying and updating these rules in GitHub repository settings is a +> manual admin action performed by Owners.