# OAuth2-Proxy Contributor Ladder This document defines the roles, responsibilities, advancement criteria, inactivity process, and interim role policies for OAuth2-Proxy contributors. It extends the standard Kubernetes-style ladder with **specialty tracks** so contributors can grow within their focus areas. --- ## Roles ### 1) Contributor Anyone making contributions of any kind (code, docs, tests, CI configs, security reports, reviews, triage, discussions). **Requirements** - For code changes all commits need to be Signed-Off by you. This is enforced through the [DCO GitHub App](https://github.com/apps/dco) - Follow the OAuth2-Proxy/CNCF [Code of Conduct](CODE_OF_CONDUCT.md) **Privileges** - Recognized as an active community member - Eligible for nomination to **Member** --- ### 2) Member Regular contributors engaged with the project for at least **3 months**. **Requirements** - Self nomination by the contributor via a GitHub Issue. - Must be Sponsored/Approved by **two Core Maintainers** (sponsorship ask must happen within the GitHub issue by tagging the sponsors). - Substantive contributions (code, docs, tests, reviews, triage) in the last 3 months. **Privileges** - Added to the GitHub `members` team. - Can be assigned issues and PRs. - Eligible for **Reviewer** nomination. --- ### 3) Reviewer (per Specialty) Experienced contributors who review changes in **one or more specialties**. **Requirements** - Member for at least **3 months**. - Regular, high-quality reviews in the specialty. - Several meaningful Issue or PR reviews over the last 3 months. **Privileges** - Listed as `reviewer` in the relevant `OWNERS` files. - May use `/lgtm` on PRs within the specialty. - Eligible for **Maintainer** nomination. > A contributor may hold different roles across specialties (e.g., **Reviewer** in Provider Integrations, **Member** in Core Proxy). --- ### 4) Maintainer (Project-Wide) Project leaders with governance, release, and cross-specialty responsibility. **Requirements** - Reviewer for at least **6 months** in one or more specialties. - Demonstrated leadership, reliability, and constructive collaboration. - Nominated and approved by a **simple majority** of Maintainers. **Privileges** - GitHub admin rights as needed. - Release management authority. - Representation within CNCF. --- ## Specialty Tracks Specialties define scope for `reviewer` permissions and expectations. ### Core Proxy Focus: Main proxy functionality, request handling, session management, authentication flow, and security implementation. **Key Responsibilities:** - Review core proxy changes in files like `oauthproxy.go`, `main.go`, and `validator.go` - Ensure adherence to [OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749) and [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) specifications - Validate security implementations, including session management, token validation, and secure cookie handling - Review authentication and authorization flow implementations - Ensure proper handling of edge cases and security vulnerabilities ### Provider Integrations Focus: OAuth/OIDC provider integrations in the `providers/` directory. **Key Responsibilities:** - Review provider-specific code changes in the `providers/` directory - Ensure conformance to OAuth/OIDC standards and provider-specific requirements - Coordinate breaking changes for provider implementations - Review provider configuration documentation - Validate provider test implementations ### Configuration / API Focus: Configuration options, API changes, and example configurations. **Key Responsibilities:** - Review configuration-related code and documentation - Ensure backward compatibility of configuration options - Review example configurations in the `contrib/` directory - Validate CLI argument parsing and validation ### Helm Chart & Kubernetes Focus: Helm chart in the separate `oauth2-proxy/manifests` repository and Kubernetes deployment configurations. **Key Responsibilities:** - Review Helm chart templates and values - Ensure Kubernetes best practices in deployment configurations - Validate Helm chart testing and CI integration - Review Kubernetes-related documentation ### Documentation Focus: Documentation in the `docs/` directory, including configuration guides, provider documentation, and tutorials. **Key Responsibilities:** - Review documentation changes for accuracy and clarity - Ensure documentation is kept in sync with code changes - Review provider-specific documentation - Validate example configurations and tutorials - Review versioning and release documentation ### CI / Automation Focus: Test implementations and CI/CD workflows across repositories. **Key Responsibilities:** - Review integration and E2E tests - Ensure adequate test coverage for new features - Review CI/CD workflows in `.github/workflows/` - Validate test infrastructure and test data - Review test automation and reporting ### Community Focus: Community nurturing, issue triage, and user support. **Key Responsibilities:** - Help with issue triage and support requests - Monitor community channels (Slack, GitHub Discussions) - Organize community talks and events - Promote OAuth2-Proxy in the community - Create demos and tutorials for users - Foster a welcoming environment for new contributors --- ### Specialty Advancement Contributors can advance in multiple specialties simultaneously. For example: - A contributor could be a **Reviewer** in Provider Integrations and a **Member** in Core Proxy - A contributor could be a **Reviewer** in both Helm Chart & Kubernetes and Testing & CI This allows contributors to focus on areas where they have expertise while still contributing to other parts of the project. --- ## Member Abuse Abuse of project resources is a serious violation of our community standards and will not be tolerated. This includes but is not limited to: * Using project infrastructure for unauthorized activities. * Misusing project funds or financial resources. * Gaining unauthorized access to or damaging project infrastructure. * Willingly engaging in activities that are against the Code of Conduct. * Willingly introducing malware or viruses to the project's infrastructure or codebase. * Any other activity that jeopardizes the project's resources, reputation, or community members. ### Procedure for Handling Abuse 1. **Immediate Revocation of Privileges**: If abuse is suspected, any maintainer can immediately revoke the member's access to all project infrastructure and resources to prevent further damage. This is a precautionary measure and not a final judgment. 2. **Investigation**: The maintainers will conduct a private investigation to gather all relevant facts and evidence. The accused member will be given an opportunity to respond to the allegations. 3. **Decision**: Based on the investigation, the maintainers will determine if a violation has occurred. 4. **Consequences**: If a violation is confirmed, consequences will be applied, which may include: - Permanent removal from the project. - Reporting the user to GitHub and other relevant platforms. - In cases of financial misuse or illegal activities, reporting to law enforcement authorities. All actions taken will be documented. The privacy of all individuals involved will be respected throughout the process. --- ## Advancement Process 1. **Nomination** by an eligible community member (Member or Higher) via a GitHub issue. 2. **Sponsorship** by two role holders at the **target level or higher** (within the specialty where applicable). 3. **Review** of activity and behavior (quality, reliability, collaboration, responsiveness). 4. **Decision** by lazy consensus of the relevant group (or **simple majority** if contested). --- ## Inactivity A **Reviewer** or **Maintainer** role holder may be considered inactive if they have not actively contributed or performed general project responsibilities for **six (6) consecutive months**. ### Measurement Sources - GitHub activity: Merged PRs, PR reviews, issue triage/comments. - Participation in community calls or asynchronous design discussions. ### Triggering Process 1. **Detection** - Activity is reviewed at least quarterly by Maintainers or via automation. - Any Maintainer may propose an inactivity review for a role holder. 2. **Notification** - A public issue is opened in a `community`/`governance` space (or email if sensitive). - The individual is tagged/emailed and given **30 days** to respond. 3. **Grace Period** - If the contributor indicates intent to return, no change is made. - If there is no response within the grace period, proceed. 4. **Decision** - Demotion is decided by **lazy consensus** of Maintainers, or **simple majority** if contested. 5. **Scope** - Demotion via inactivity fully removes the role holder from the organization. 6. **Documentation** - Update `OWNERS`, GitHub teams, and governance records. - Former Members may be listed as **Emeritus**. ### Reinstatement A contributor can be reinstated at their previous level via the standard advancement process. Prior history is considered favorably. --- ## Emeritus Status Emeritus status recognizes former Maintainers, Reviewers, or Members who have made substantial and lasting contributions to the OAuth2-Proxy project but are stepping down from active responsibilities. Emeritus status is honorary and does not confer any formal responsibilities or authority. ### Purpose * Honor and recognize long-term contributions. * Preserve institutional knowledge and mentorship potential. * Encourage continued engagement with the community without requiring full role responsibilities. --- ## Cross-References - Project governance and decision-making: see [GOVERNANCE.md](GOVERNANCE.md) - Specialty ownership: [CODEOWNERS](./.github/CODEOWNERS) files per directory