-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nonspec: Add Pavel to maintainers #1271
nonspec: Add Pavel to maintainers #1271
Conversation
Signed-off-by: Marcela Melara <[email protected]>
✅ Deploy Preview for slsa canceled.
|
I think my only qualm, if I'm going to be especially pedantic, is that I can't find much public contribution from @paveliak to this project? Am I a) doing it wrong, you can see everything he's contributed HERE? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Seeing as how no one else is concerned, I'll retract my (minor) objection. Welcome Pavel! |
I actually feel a bit the same as Tom. It seems a bit odd to make someone who hasn't made a single commit a maintainer and doesn't show up in the list of contributors at all. This said, making a commit isn't a requirement. Our doc states that:
So, as long as the above is true it is fine, but it might be worth making that claim explicit. |
The point about prior commits is fair, though I will say that my recommendation is based primarily on the third criterion:
We have, in the past, considered giving track shepherds maintainership, and with Triage permissions (which Pavel already has), he still hasn't been able to help me manage issues and PRs to the full extent needed to help the track progress. We also expect that @paveliak will be making actual commit contributions in the near future to this end. But I defer the final decision to the majority of the current maintainers. |
For what it is worth, I chose to abstain from voting because I am not familiar with what his contributions have been. |
Agree that lack of commits does not suggest that the Maintain role is appropriate. However, as @marcelamelara says, Pavel would need to assume the Triage role to manage issues, discussions, and PRs. Currently, we don't have a distinction between the two in our governance. Either we make room in the governance for a new group called SLSA Triagists (in line with name for role in medicine), or we clarify that Maintainers need not commit but only triage. |
I appreciate the discussion. I do think that, if being a track shepherd isn't a sufficient contribution to become maintainer, we ought to emphasize the requirement for commits/merged PRs (maybe even set a min. expectation?) in our Contributing.md. Either way, I'm not going to stand in the way of deferring this request if the majority of the other maintainers feel strongly about this. |
I thought I'd chime in with my reasoning for the approval from before. I think it's worth noting that a) the SLSA maintainers decided the track is worth adding to the SLSA spec, and b) have already approved @paveliak as a shepherd for the track. I understand that shepherding is considered one way to demonstrate contributions to get maintainer bit (i.e., shepherding doesn't automatically mean you're a maintainer), but I want to highlight that Pavel's been reviewing PRs for this track (#1115, #1244) and, in the latter case, is even relied upon by maintainer(s) as a subject matter expert for changes to the track. Maybe this really means we need to (re-?)consider discussing maintainer bit on a track-by-track basis or so? |
To clarify, I pointed out in my comment that making commits is NOT required and I didn't mean to imply that we should modify that. My point was really meant to be that it's easy to figure out one's contribution when they have made commits and when it's not the case their contribution should be described as much as possible to back up the request. I think "He contributes as co-shepherd of the attested build environment track" is a bit weak. But I'm not going to stand in the way of approving Pavel as a maintainer. Again my motivation is primarily to document our decision as well as possible to avoid raising any questions. |
This is great feedback, thank you, @lehors ! And tbqh, I didn't expect to need to show ample evidence, when there have been various interactions with maintainers and community members on other PRs already. Anyway, I'm happy to add a list of key examples of contributions to be abundantly clear, if that'll help. And for future reference I still think it's reasonable to amend Contributing.md to ask for a few examples, if commits haven't been the primary contribution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the added info!
I count approval from 5 current maintainers to which we can add @marcelamelara. This gives us: 6 approve, 1 abstain, out of the 9 current maintainers. This meets the majority requirement. |
Requesting to add @paveliak as a maintainer. He contributes as co-shepherd of the attested build environment track, so being able to manage issues and approve PRs in this track would be really helpful.
Relevant contributions to the track: