community icon indicating copy to clipboard operation
community copied to clipboard

ROLES.md does not reflect the roles that actually exist within Knative

Open geekygirldawn opened this issue 3 years ago • 4 comments

During a discussion about a TOC candidate in PR #1039, it was mentioned that we don't really have a clear path to becoming an approver, which lead me to do a review of the existing ROLES.md file, which has members and approvers, but not reviewers. In looking at knative.yaml, we also have a reviewers role in between member and approver that is undocumented. I think we should add the reviewer role to ROLES.md.

I also think that we should improve the ROLES.md file to more clearly describe the process required to move from member to reviewer to maintainer using a contributor ladder approach. We have a CNCF template for the contributor ladder, and I think we could merge some things from that template into your existing ROLES.md file to make the process of moving into leadership roles easier and more clear.

I'm happy to help someone with this, but I don't have the bandwidth to take this on right now.

cc: @lance @csantanapr @jberkus @vaikas

geekygirldawn avatar May 06 '22 13:05 geekygirldawn

Hi @geekygirldawn thanks for bringing this up. I have been thinking about this and I am wondering (may have been discussed before): a) major contributors in an area shouldnt be approvers anyway? For example someone may not reach the required reviews but has written most parts of the code. The guy who reviews the PRs becomes the approver without writing any code? Could be but feels kind of misleading although mentally both have almost equal understanding of the code base. b) in project with low traffic it must take for ages to become an approver. Any alternative paths there? c) other skills matter for PR reviews beyond technical matters and code quality, to make sure community goals are reached. Should not these considered as prerequisites and not just part of duties?

/cc @vaikas @dprotaso @rhuss @lance

skonto avatar May 11 '22 11:05 skonto

a) major contributors in an area shouldnt be approvers anyway? For example someone may not reach the required reviews but has written most parts of the code. The guy who reviews the PRs becomes the approver without writing any code? Could be but feels kind of misleading although mentally both have almost equal understanding of the code base.

Keep in mind that the contributor ladder is a template, and I am not suggesting that we just copy it over and use it. We are expected to (and will) heavily adjust it and customize it for Knative. It's roughly based on the one from Kubernetes, so I expect that most of those numbers are higher than what we would want to use.

The ladder is mostly to provide people with ideas for how they might move up into roles with increasing responsibilities. People will have different skills and different ways of proving that they are ready for a next role. The important piece for us to define is how the decision is made for someone to move up. In most cases, it's a certain number of maintainers vouching for that person in some way, and we can decide how we want that to work for Knative.

b) in project with low traffic it must take for ages to become an approver. Any alternative paths there?

We'll define things in a way that makes sense for Knative and gets people into approver roles within a reasonable period of time. As I mentioned, this is a template that we will need to modify.

c) other skills matter for PR reviews beyond technical matters and code quality, to make sure community goals are reached. Should not these considered as prerequisites and not just part of duties?

Absolutely! For example, as part of my role as an election officer, I'm an approver for several elections folders despite never having contributed code to Knative. As part of this role, I also review quite a few PRs. There are certainly other people contributing in a bunch of other areas beyond code. The language in the contributor ladder template is carefully worded to avoid assuming that contributions are code, in fact, it explicitly says that "A Contributor contributes directly to the project and adds value to it. Contributions need not be code." I would expect for us to adopt a similar mindset and be welcoming of all contributions.

Taking this idea, adapting it to Knative, and adopting it will take a fair bit of time and participation from the community, which is why I said that I don't have the bandwidth to do it right now ... maybe a few of us can tackle it after KubeCon :)

geekygirldawn avatar May 11 '22 14:05 geekygirldawn

/assign @lance

lance avatar Jul 21 '22 16:07 lance

@lance Let me know if you'd like any help / feedback on this. As part of my other role as CNCF TAG Contributor Strategy co-chair, we frequently help projects with these sorts of things, so I'm happy to review something or brainstorm if you want suggestions.

geekygirldawn avatar Jul 22 '22 08:07 geekygirldawn

Just for clarification -- "reviewers" is a way to get Prow to assign issues to you automatically so you get a stream of PRs to review without needing to watch for them. I think the requirements are equal to the "member" role, but it's a means to help indicate that you're looking to get the review requirements completed to get to "approver".

evankanderson avatar May 04 '23 20:05 evankanderson

@lance Are you still working on this or would you like for me to draft something?

geekygirldawn avatar May 05 '23 06:05 geekygirldawn

@geekygirldawn "still" 🤣 - I put it on the back burner for months, but am now about halfway through an update to the document. I'm using the CNCF template that you referenced in the issue description, and adding a "Contributor" role to our doc. I should be able to open a PR today and your feedback/commentary would be most welcome.

lance avatar May 05 '23 14:05 lance