Contributor Ladder

Overview

SeeBOM uses a transparent contributor ladder inspired by the CNCF contributor ladder template. Each rung provides clear expectations and privileges, so you always know what the next step looks like.

┌─────────────────────────────────────────────┐
│  Maintainer   — merge, release, direction   │
├─────────────────────────────────────────────┤
│  Reviewer     — approve PRs in their area   │
├─────────────────────────────────────────────┤
│  Contributor  — regular code/docs/tests     │
├─────────────────────────────────────────────┤
│  Community    — issues, discussions, usage   │
└─────────────────────────────────────────────┘

🌱 Community Member

Who: Anyone who uses SeeBOM, files issues, or participates in discussions.

How to become one: Just show up! No formal process.

Expectations:

• Follow the Code of Conduct
• File bugs and feature requests using the issue templates
• Help answer questions in discussions

Privileges:

• Open issues and participate in discussions
• Submit pull requests

🔧 Contributor

Who: Community members who have had at least one pull request merged.

How to become one: Get a PR merged. That’s it.

Expectations:

• Sign off commits (Developer Certificate of Origin: git commit -s)
• Follow coding standards (see Development Guide)
• Write tests for new features
• Respond to review feedback in a timely manner

Privileges:

• Listed in release notes as a contributor
• Can be assigned to issues
• Eligible for help wanted and good first issue tasks

Good First Contributions

Coding Standards Quick Reference

👀 Reviewer

Who: Contributors who have demonstrated sustained, high-quality contributions in a specific area and are trusted to approve PRs.

How to become one:

1. Have 5+ merged PRs in the area you want to review
2. Demonstrate understanding of the codebase architecture and conventions
3. Nominated by a maintainer, confirmed via lazy consensus (no objection in 7 days)

Expectations:

• Provide timely, constructive reviews (target: 48h for first response)
• Ensure code quality, test coverage, and documentation
• Help mentor new contributors
• Prioritize unblocking others over your own PRs

Privileges:

• Can approve PRs in their area (final merge still requires maintainer)
• Listed in OWNERS file
• Invited to architecture discussions

Review Areas

🛡️ Maintainer

Who: The project’s technical leadership with full write access and release authority.

How to become one:

1. Be an active Reviewer for 3+ months
2. Demonstrate deep understanding of the full architecture (not just one area)
3. Show good judgment on API design, security, and backward compatibility
4. Nominated by an existing maintainer, approved by supermajority (⅔) of current maintainers

Expectations:

• Set technical direction and own the Roadmap
• Review and merge pull requests across all areas
• Cut releases (tag → CI → publish)
• Manage CI/CD pipeline and infrastructure
• Enforce Code of Conduct and resolve disputes
• Mentor reviewers and contributors
• Be responsive: triage new issues within 7 days

Privileges:

• Write access to the repository
• Merge pull requests
• Cut releases
• Manage GitHub project board and labels
• Represent the project externally

Current Maintainers

🏛️ Emeritus

Maintainers or reviewers who are no longer active may be moved to emeritus status. This is a recognition of past contributions, not a demotion. Emeritus members:

• Are listed in project history with gratitude
• No longer have active review or merge permissions
• Can return to active status by request + re-confirmation from current maintainers

Promotion Process

Community → Contributor:     First merged PR (automatic)
Contributor → Reviewer:      Nominated by maintainer, 7-day lazy consensus
Reviewer → Maintainer:       Nominated by maintainer, ⅔ supermajority vote
Active → Emeritus:           Self-request or 6 months of inactivity + maintainer consensus

What We Look For

Beyond code quantity, promotion decisions consider:

• Quality — Are PRs well-tested, documented, and maintainable?
• Consistency — Are contributions sustained over time (not just a burst)?
• Collaboration — Do you help others, respond to reviews, and communicate well?
• Judgment — Do you make good trade-offs? Do you know when to ask vs. decide?
• Alignment — Do your contributions advance the project’s mission and roadmap?

🤖 AI Usage Policy

We welcome AI-assisted contributions. See the dedicated AI Usage Policy for full guidelines.

Key points:

• AI usage is welcome — you are responsible for the output
• DCO sign-off (git commit -s) is mandatory — you sign, not the AI
• No Co-authored-by: AI trailers — AI is a tool, not a co-author
• Follow AGENTS.md conventions

Getting Started

Ready to climb the ladder? Here’s how:

1. Browse issues labeled good first issue or help wanted
2. Set up your dev environment — see Development Guide
3. Read the architecture — see Architecture
4. Submit a PR — follow the Contributing Guide
5. Check the Roadmap — see Roadmap for what’s planned next