public_git
/
oauth2-proxy
mirror of https://github.com/oauth2-proxy/oauth2-proxy.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
oauth2-proxy/CONTRIBUTOR_LADDER.md

9.8 KiB
Raw Blame History

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
  • Follow the OAuth2-Proxy/CNCF Code of Conduct

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 and OpenID Connect Core 1.0 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