Skip to content

Conversation

@adambkaplan
Copy link
Member

Changes

Document a contributor ladder for Shipwright, which serves the following purpose:

  • Clarify the roles and responsibilities of community members.
  • Identify levels of leadership within the community.
  • Provide guidance and procedures for adding new maintainers and other roles that grant permissions for project behaviors/functions.
  • Map project roles to security roles in GitHub.

This ladder was inspired by several contributor ladder documents in the CNCF, such as the CNCF Glossary project [1] and the OpenFeature project [2].

[1] https://glossary.cncf.io/contributor-ladder/
[2] https://openfeature.dev/community/contributor_ladder/

Assisted-by: Cursor
Generated-by: Cursor

Fixes #244

/kind feature

Submitter Checklist

  • Includes tests if functionality changed/was added
  • Includes docs if changes are user-facing
  • Set a kind label on this PR
  • Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

Document contributor ladder

Document a contributor ladder for Shipwright, which serves the
following purpose:

- Clarify the roles and responsibilities of community members.
- Identify levels of leadership within the community.
- Provide guidance and procedures for adding new maintainers and other
  roles that grant permissions for project behaviors/functions.
- Map project roles to security roles in GitHub.

This ladder was inspired by several contributor ladder documents in the
CNCF, such as the CNCF Glossary project [1] and the OpenFeature
project [2].

[1] https://glossary.cncf.io/contributor-ladder/
[2] https://openfeature.dev/community/contributor_ladder/

Assisted-by: Cursor
Generated-by: Cursor
Signed-off-by: Adam Kaplan <[email protected]>
@pull-request-size pull-request-size bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 8, 2026
@openshift-ci openshift-ci bot added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 8, 2026
@openshift-ci
Copy link

openshift-ci bot commented Jan 8, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign qu1queee for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ayushsatyam146
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 10, 2026
@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 12, 2026
@openshift-ci
Copy link

openshift-ci bot commented Jan 12, 2026

New changes are detected. LGTM label has been removed.

Copy link
Member

@SaschaSchwarze0 SaschaSchwarze0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that you now also changed the permissions. Would not an approver also only need Write permission ? The difference to Contributor would be to be listed as approver in the OWNERS files. Maintainer would then have Maintain permission. Or, do you have use cases in mind where an approver would require maintain permissions ?

@adambkaplan
Copy link
Member Author

adambkaplan commented Jan 12, 2026

I see that you now also changed the permissions. Would not an approver also only need Write permission ?

Taking a harder look at this, you are right that I should revert the defaults. Write permission is sufficient for an Approver across the board. Maintain is a middle ground between Write and Admin that covers a few admin tasks that we don't really need right now.

Also, Contributor should have the default role be Triage, since Write permission grants permission to create and edit releases. Unfortunately those with Triage permission can't manage GitHub action workflows - we simply need more Approvers to handle this!

Per feedback from the community:

- Grant GitHub permissions across the organization based on contributor
  level.
- Recognize approvers in the maintainers list document.

Signed-off-by: Adam Kaplan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/feature Categorizes issue or PR as related to a new feature. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

Define Project Roles

3 participants