Adopt a contributor ladder

[pnacht]

Currently, the only projects with contributor ladders are Sigstore and AllStar.

As recognized in https://github.com/ossf/scorecard/issues/1529 and https://github.com/ossf/criticality_score/issues/312, having a generally-applicable contributor ladder across all OpenSSF projects (which they may then customize according to their needs) would allow engaged community members who want to increase their participation to know how they can (eventually) become a maintainer for projects.

Here's a proposed draft Contributor Ladder. It's currently written as all-encompassing and applying to all projects, but it can be simplified to apply to a single project if you'd prefer a template that each project copies instead of referring to a central file.

[SecurityCRob]

@TAC please review this for our 13June call. This may get addressed as part of/in concert with https://github.com/ossf/tac/issues/162 , https://github.com/ossf/tac/issues/161 , and https://github.com/ossf/tac/issues/169

[lehors]

I think it would be fine to have this as a template for projects to use if they want to but I wouldn't want to impose it on every project. While this makes sense for big projects with a large community for many projects this would just be overkill in my opinion.

At the same time I do support the idea of documenting who the maintainers/codeowners are along with the policy and mechanism used to update that list. I think we should have an organization wide policy requiring that from all projects.

[znewman01]

Was that supposed to be @steiza assigned instead of me?

[di]

Agreed that this should be thought of as a template for a contributor ladder rather than a mandate to accept this exact contributor ladder. That said, I do think we should require all projects to have some form of contributor ladder (this probably relates to #162).

[david-a-wheeler]

How about this being the "default" contribution ladder, and saying, "OpenSSF projects should (must?) have a contribution ladder, here's the default ladder"?

[ljharb]

Why should such a formal process be a requirement?

[david-a-wheeler]

@ljharb - whether or not it's a requirement is up to the TAC. I think the argument for a contribution ladder is that it encourages contributors to take various positive steps. See the proposal.

[ljharb]

I saw it - to me it feels like an artificial hierarchy, much like assuming engineers should naturally become managers. The goal of contribution shouldn't necessarily be escalation imo, and the skills required to excel in one role are not necessarily the same as the skills required in another.

In other words, I don't think "ladder" is at all the right mental model here in a generic sense.

[lehors]

I'm with @ljharb on this. I think this is too heavy to be the default. In my opinion, by default a project should merely be required to document its list of maintainers and the policy and mechanism governing changes to that list.

We shouldn't add bureaucracy that may scare possible contributors away until it is necessary.

[di]

I saw it - to me it feels like an artificial hierarchy, much like assuming engineers should naturally become managers. The goal of contribution shouldn't necessarily be escalation imo, and the skills required to excel in one role are not necessarily the same as the skills required in another.

The ladder isn't a requirement for contributors by any means, it just describes the agreed upon path towards maintainership should a contributor have that as a goal.

I'm suggesting that the requirement should be for OpenSSF projects to have and maintain such a document. This solves a real-world problem with projects like Scorecard (ref https://github.com/ossf/scorecard/issues/1529) where it's very unclear how and when contributors should be given increasing responsibilities towards maintainership in a fair an equitable way.

That project has contributors that want to become maintainers, but are unsure how to do it, and the existing maintainers are unsure as well! We stand a real risk to lose interested contributors if the path forward is unclear.

We shouldn't add bureaucracy that may scare possible contributors away until it is necessary.

If a contributor doesn't want to become a maintainer, they can just ignore the ladder entirely, I don't see how it would be burdensome for them.

[dlorenc]

Agree with Dustin's comments here. We should ask OpenSSF projects to maintain such a document, and we can provide a template to make it easier. We shouldn't require projects to use a specific format, and we can't/shouldn't require contributors to follow it.

[lehors]

Just to clarify my position on this: I do agree that every project must document how one can contribute to the project and become a maintainer. They also need to document the current list of maintainers for that matter. But I think that's all that should be required.

I have no problems also defining a more sophisticated ladder with different possible roles for projects that want that but how much of that is adopted should be left to each project.

I think this approach would be flexible enough to address all projects needs and provide consistency across projects, without imposing a structure that might just be unnecessarily complicated for some.

[di]

Just to clarify my position on this: I do agree that every project must document how one can contribute to the project and become a maintainer. They also need to document the current list of maintainers for that matter. But I think that's all that should be required.

Sorry @lehors , I think I'm missing what you don't think should be required. The draft contributor ladder is just focused on the "document how one can contribute to the project and become a maintainer" requirement.

I have no problems also defining a more sophisticated ladder with different possible roles for projects that want that but how much of that is adopted should be left to each project.

+1

[lehors]

Just to clarify my position on this: I do agree that every project must document how one can contribute to the project and become a maintainer. They also need to document the current list of maintainers for that matter. But I think that's all that should be required.

Sorry @lehors , I think I'm missing what you don't think should be required. The draft contributor ladder is just focused on the "document how one can contribute to the project and become a maintainer" requirement.

The minimum required should be a ladder that only has two rungs: contributor and maintainer. :-)

I hear you say that it's meant to help people understand how to engage but the way it is laid out with all the different roles with their requirements and responsibilities feels quite daunting to me. Maybe this could be mitigated somehow but as it stands I would expect it to scare people away rather than invite them to jump in and help out.

[di]

I think I understand: the issue is that the template has too much detail, and that a project might not feel able to modify or remove these details it they choose to adopt it?

[lehors]

I think I understand: the issue is that the template has too much detail, and that a project might not feel able to modify or remove these details it they choose to adopt it?

Yes.

[jeffmendoza]

Agree with the others here. The proposed ladder is a great start for the Scorecard project, but is way too complicated and heavy to serve as template or default for new/small projects across the foundation.

I support the requirement for all projects to have a contributor ladder with the requirements that Arno laid out above. Either a very simple template/default should be provided, or, as Dustin suggested, no template and only links to examples.

[di]

OK, I've made https://github.com/ossf/tac/pull/184 which should resolve this.

[ctcpip]

Strongly disagree with a contributor ladder at all. Very strongly disagree with a contributor ladder as a requirement. This is not in keeping with the spirit of open source.

Strong support for documenting maintainers.

edit: allow me to elaborate. a ladder is a concept clearly defined as being competitive in nature. what we should be trying to foster is cooperation, not competition.

in other spaces, I, along with my colleagues, already struggle with a stigma where would-be contributors, because they are not a part of some in-group are completely discouraged from participation. not because of any actual barrier to their participation, but because they perceive that if they are not in group x, then they cannot contribute, or their contributions will be disregarded. it's not true of course, but because that's the perception, it keeps them from participating.

I don't believe the intent with what is being proposed here is to be exclusionary in any way. I only encourage everyone involved to think hard about how building these boundaries will have a chilling, exclusionary effect on participation.

[di]

Thanks for the feedback @ctcpip. The intent here is definitely not to exclude any potential contributors (rather, the opposite).

Taking a step back: the problem that we're trying to solve here is that by default, projects already have at least two distinct groups: "maintainers" (can merge code) and "contributors" (cannot merge code). This raises the following questions:

• If a contributor wants to become a maintainer, what do they have to do?
• Once a contributor is a maintainer, what privileges/responsibilities do they get?
• How do we ensure that maintainers are added in a fair, equitable, and transparent way?

The things we're trying to avoid are:

• A contributor shows up to a project, wants to work on becoming a maintainer, but the path is unclear and they become discouraged
• A contributor spends a lot of time working on a project, feels like they've done enough to deserve maintainership but the maintainers disagree because expectations are unclear
• A contributor spends a lot of time working on a project, but the existing set of maintainers are unsure when it's appropriate to add them as a maintainer, because the process has been inconsistent in the past
• A contributor spends a lot of time working on a project, but the existing set of maintainers disagree when they should be added, because they have different expectations
• A set of maintainers only adds new maintainers that they work with / know personally / etc, excluding others
• A new maintainer is added, but they only merge their own PRs, or their colleagues PRs, and don't provide reviews, triage issues, etc.

It seems like folks are getting hung up on the name "ladder" but I'm not at all tied to this, I just took it from the existing examples. Perhaps calling this a "membership guide" or "path to maintainership" or something similar would be preferable?

Regardless of what we call it, I do think projects at a certain stage in the project lifecycle do need to a) define what it takes to become a maintainer b) hold themselves to that definition when adding new maintainers, to make it clear that it is possible for anyone to move from the "contributors" group to the "maintainers" group.

[joshuagl]

I'm sorry to hear of you and your colleagues having negative experience contributing to projects @ctcpip.

I came here to say something similar, though less eloquently, than @di. Contributor ladders are explicitly designed to foster growth in the community, incentivize, and recognise contribution. In support of what Dustin wrote, I wanted to link to the CNCF contributor documentation, which contains a good summary of the why and how of contributor ladders: https://contribute.cncf.io/maintainers/community/contributor-growth-framework/incentivizing-contributors/

[lehors]

I think indeed the term "community ladder" has quite a negative connotation which is why several people are having a negative reaction to the proposal (me included). It seems to be putting additional hurdles on the path to becoming a maintainer rather than providing a way to ramp up to it. So, I think considering a new name would help indeed.

[ctcpip]

I'm sorry to hear of you and your colleagues having negative experience contributing to projects @ctcpip.

@joshuagl I think you misunderstood what I said there. We don't have negative experiences contributing. We (the in-group) struggle with trying to encourage (perceived) outsiders to contribute when they don't feel like they are part of the in-group.

@di I agree with probably everything you've pointed out there, and yes, the semantics of the word ladder and its use in other contexts doesn't help things here. It may seem pedantic, but the words we choose have greater consequences than we sometimes think. And just calling it a contribution/contributing/contributor guide is perhaps adequate and can avoid some of the unwanted connotations.

I agree with the spirit of what is being proposed and not leaving contribution guidance to whim and ambiguity. Actually, it sounds like we are all more-or-less aligned on this item and the hang-up might be limited to semantics/terminology.

[joshuagl]

@joshuagl I think you misunderstood what I said there.

I did, apologies for the misunderstanding.

I agree with the spirit of what is being proposed and not leaving contribution guidance to whim and ambiguity. Actually, it sounds like we are all more-or-less aligned on this item and the hang-up might be limited to semantics/terminology.

🎉

[di]

If anyone opposed to the term "contributor ladder" would mind proposing a term they would prefer instead, I'd appreciate it!

[ctcpip]

off the top of my head: contributor|contribution|contributing guide|schedule|matrix|roles

[di]

I've chosen "contributor guide" and updated #184 accordingly.