3.2 KiB
Maintainers
This file lists who maintains career-ops and how contributors grow into review and maintenance roles. It exists so the project doesn't depend on any single person and so the path forward is legible to everyone.
Current maintainers
| Role | Who | Areas |
|---|---|---|
| Lead maintainer | @santifer | All areas; final say on architecture, scoring, and the data contract |
Reviewers and additional maintainers are added as the contributor ladder below produces them. If you're reviewing this and the list is short — that's the honest current state, and the ladder is how it grows.
The contributor ladder
Career-ops grows its team in the open. There are three rungs:
1. Contributor
Anyone who opens a PR or a helpful issue. No permissions needed — just contribute. Good first contributions: a new open-API scanner provider (providers/), a translation, a docs fix, or a good first issue. See CONTRIBUTING.md.
2. Reviewer
Trusted contributors who help triage and review incoming PRs. A reviewer is invited after a track record of several merged, high-quality PRs across more than one area, plus consistently helpful review comments on others' PRs. Reviewers help label, reproduce, and give first-pass feedback; merges still go through a maintainer.
How to get there: keep shipping quality PRs, review others' work thoughtfully, and engage in discussions/RFCs. Identity is verified before any access is granted (see "Trust & access" below).
3. Maintainer
Reviewers who have shown sustained judgment aligned with the project's direction (local-first, AI-agnostic, human-in-the-loop) can be invited to maintain — with merge rights and a voice in architecture decisions.
What each rung can do
| Contributor | Reviewer | Maintainer | |
|---|---|---|---|
| Open PRs / issues | ✅ | ✅ | ✅ |
| Triage & label | ✅ | ✅ | |
| First-pass review | ✅ | ✅ | |
Merge to main |
✅ | ||
| Architecture / scoring / data-contract decisions | ✅ |
Trust & access
Because career-ops handles people's personal career data, access is granted carefully:
- Generous with credit, careful with access. Praise and shout-outs are public and frequent; merge/admin rights are earned and verified.
- Identity is verified before granting review/maintainer access (real-identity footprint, account history). This protects the candidate side of the project.
- The codebase stays MIT and the data contract (system vs. user layer) is never weakened to grant convenience.
Decision-making
- Day-to-day: lowest-friction path — a maintainer reviews and merges.
- Significant or breaking changes: an RFC first (see CONTRIBUTING.md → "Proposing big changes").
- Architecture, scoring rules, and the data contract: lead maintainer has final say, informed by RFC discussion.
Want to help maintain?
Start by contributing, review others' PRs, and engage in RFCs. If you're consistently shipping quality work and want to take on more, say so in a discussion or reach out — the door is open.