From f3f3bdd5259e9859886bf4b5a4d786917ac4d28f Mon Sep 17 00:00:00 2001 From: Natalia Luzuriaga Date: Tue, 24 Mar 2026 08:23:50 -0700 Subject: [PATCH] Add contributor_ladder.md Signed-off-by: Natalia Luzuriaga --- content/outbound/contributor-ladder.md | 46 ++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 content/outbound/contributor-ladder.md diff --git a/content/outbound/contributor-ladder.md b/content/outbound/contributor-ladder.md new file mode 100644 index 0000000..0887505 --- /dev/null +++ b/content/outbound/contributor-ladder.md @@ -0,0 +1,46 @@ +--- +title: Contributor Ladder +description: Guidelines for receiving contributions in open source repositories +permalink: /outbound/contributor-ladder/ +layout: layouts/page +section: outbound +tags: ospo +eleventyNavigation: + parent: ospo-outbound + key: ospo-outbound-contributorladder + order: 13 + title: Contributor Ladder +sidenav: true +sticky_sidenav: true +--- + +| Contribution Type | Description | +| ----- | ----- | +| **Share Repo (Outbound Contribution)** | This initial step involves sharing the project with a wider audience to attract potential contributors and users. | +| **Accepting Issues (Inbound Contribution)** | This is a crucial first step for receiving feedback and bug reports from the community. It allows users to start engaging with the project. | +| **Accepting Pull Requests (PRs)** | This is where collaborative coding begins. You can start by accepting PRs that are directly linked to existing issues. | +| **Accepting Roadmap Input** | As the project matures, you can open up the roadmap for community input, allowing contributors to help shape the future direction of the project. | +| **Accepting External Reviewers** | This involves inviting trusted community members to review code and other contributions, which helps to scale the project and improve quality. | +| **Accepting Community Governance** | At the highest level of maturity, a project can be governed with the community, by elected or appointed leaders from the contributor base. | + +## Pull Request Guidelines + +We don’t accept PRs that: +- Don’t directly address an existing issue +- Touch more than X files at a time +- contain more than Y commits +- Change core system files such as … +- Are untested / don’t pass our test suite / don’t pass our linters / don’t follow styleguide +- Are entirely AI generated + +We accept feedback in the form of issues for the following: bug reports, feature requests + +**Reducing the risk of Extractive Contributions** +- Limiting PRs/contributions to existing tickets reduces the risk of ‘roadmap drift’ where contributions take away limited time/energy/attention from the established priorities of the project. +- Limiting files and commits and file surface reduces the ‘splash radius’ and review time needed from a human. +- Test suite, linters, styleguides ensure that contributions meet our requirements, do not introduce breaking changes, and keep a consistent voice/brand/culture. +- These are built to reduce extractive contributions from HUMANS first, and also limits extractive AI contributions as a side-effect. +- Turns reviews from a high-effort one-off evaluation, into a checklist. Checklists are made for Humans. They create structured spaces for intentional, participatory transition, that reduce cognitive and actual burden and effort. +- Machine-readable metadata can be derived from metrics, but human judgement prevails, and communication is human-readable, by and for people. +Templates for responding to extractive contributions can be copy-pasted and automated to encourage contributions that follow the guidelines, without the maintainers needing to custom-respond to every PR. +- It’s not humans versus machines, it’s clarity v.s. ambiguity. \ No newline at end of file