Contributor Hierarchy

LinkML uses a lightweight four-level contribution structure. It exists to make expectations, permissions, and growth paths transparent across all LinkML repositories.

The goal is not gatekeeping — the goal is to make it obvious how people grow into responsibility over time, and to ensure that every PR has a clear path to review and merge.

Overview

Level

Team

Write access

Can merge?

Required reviewer?

1. Community contributor

—

No (forks only)

No

No

2. Collaborator

developers-collaborators

Broad write

Only in areas where they are a CODEOWNER

Only in CODEOWNER areas

3. Core developer

core-team

Broad write

Yes (within branch protection)

Only where explicitly listed in CODEOWNERS

4. Admin

admin

Admin

Yes

Only where explicitly listed in CODEOWNERS

Team URLs are only visible to members of the LinkML GitHub organization.

1. Community contributor

The default and most important entry point. Zero friction.

Typical characteristics:

  • Not (yet) deeply embedded in the LinkML ecosystem

  • Works via forks

  • Not part of any GitHub team

  • No need to request membership or permission to open PRs

If you want to fix a bug, file an issue, or suggest an improvement — just do it. You do not need to be on any team.

2. Collaborator

Team: developers-collaborators

Regular contributors who are trusted with broad write access across LinkML repos, but are not expected to merge arbitrary changes.

Capabilities:

  • Broad write access across many LinkML repos

  • Cannot merge by default

  • May request CODEOWNERS status for specific areas they maintain (e.g., a generator)

  • Once listed as a CODEOWNER for an area, may review and approve PRs in that area

Expectations:

3. Core developer

Team: core-team

People actively stewarding LinkML as a whole.

Capabilities:

  • All collaborator capabilities

  • Can review and approve PRs anywhere in the monorepo (team write access is sufficient; CODEOWNER approval is only required for paths explicitly listed in the CODEOWNERS file)

  • May invoke the 1-month CODEOWNER fallback to approve stalled PRs in areas with unresponsive CODEOWNERS

  • Still subject to branch protection rules (cannot force-push, etc.)

Expectations:

  • Participate in LinkML developer calls

  • Help triage issues and review PRs across the project, not just your own patches

  • Mentor collaborators and community contributors

4. Admin

Team: admin

Small group responsible for repo-level governance.

Capabilities:

  • Manage GitHub organization and repository settings

  • Adjust branch protection rules when necessary

  • Manage team membership

Admins are typically appointed by existing admins as responsibility transitions over time. There is no formal democratic process, but the group is intentionally small and accountable to the core team.

How to ascend

Progression is contributor-initiated, not top-down. You ask; existing members review.

Community contributor → Collaborator

  1. Have roughly three merged PRs across any LinkML repository. The number is a soft floor, not a hard rule — the point is to demonstrate sustained engagement and familiarity with the review process.

  2. Open an issue in linkml/linkml requesting collaborator status. Include:

    • Links to the merged PRs

    • A short note on what areas you expect to contribute to

    • (Optional but encouraged) an ORCID linked to your GitHub account — this helps with long-term attribution across the dependency graph

  3. A member of the core team or admin will review and add you to the developers-collaborators team if approved.

Collaborator → CODEOWNER for a specific area

See CODEOWNERS for the full process. In short: demonstrate sustained, quality contributions to a specific area (generator, validator, subsystem), then open a PR adding yourself to .github/CODEOWNERS for that path. The PR description must link to at least three merged PRs in that area that justify codeownership.

Collaborator → Core developer

  1. Sustained contribution over time. As a soft guideline:

    • Roughly ~10 merged PRs

    • Regular review activity (a rough target: ~1 completed issue + ~2 PR reviews per week, sustained over several weeks)

    • Intent to participate in LinkML developer calls

  2. Open an issue requesting core developer status, linking to your contribution and review history.

  3. The existing core team discusses and — if there is rough consensus — an admin adds you to the core-team team.

Core developer → Admin

Admin status is not requested; it is offered. When an existing admin needs to step back, or when the project’s administrative load grows, the existing admins invite a core developer to take on the role. If you have thoughts on who should be an admin, raise them in a governance issue.

Stepping back

Contributing to LinkML is voluntary. If your circumstances change and you need to reduce your involvement, that is fine and expected. Open an issue or ping an admin and we will move you to a level that matches your current capacity. You can always come back.

Admins may also periodically review team membership and move inactive members to a lower tier, with notice. The intent is to keep the active teams reflective of who is actually engaged, not to penalize anyone.