community : Contributor ladder

[naveensrinivasan]

Description

I am opening this to ask if there's a contributor ladder defined for sigstore.
How do I become an org member?

I would be happy to help do PR's reviews here, hoping to work towards maintainership.

previous contributions - mainly fuzzing sigstore and integrating with oss-fuzz

PR's in sigstore

1. Moved dsse to fuzz dir #214
2. Fuzz - Fixed the panic that was caused by incorrect data #213
3. Fuzz- Fixes the invalid UTF-8 string for DSSE #212
4. Fuzz - Fixes nil data #197
5. Upgraded go-securesystemslib from 0.1.0 to 0.2.0 #178
6. Additional corpus for ecdsa and ed25519 #177
7. Fuzz testing DSSE #173
8. Fuzzing for RSAPASS #170
9. Included CIFuzz #169
10. Included fuzz badge #168
11. Docs for Fuzzing #165
12. Fuzzing - Included RSA Targets #164
13. Fuzzing password and some signature API #160
14. clusterfuzz lite #158
15. Included fuzzing for more cryptoutils #157
16. Linter - Included linter check for doc rules #148
17. Feat : Fuzzing #146
18. Create dependabot.yml #127

oss-fuzz and actively maintaining the oss-fuzz issues

1. Fuzzing sigstore google/oss-fuzz#6890
2. sigstore-Included additional fuzzing targets google/oss-fuzz#6927
3. sigstore - Included corpus google/oss-fuzz#6964

Issues in sigstore

https://github.com/sigstore/sigstore/issues?q=is%3Aissue+author%3Anaveensrinivasan

PR's in cosign

1. cjson - Move to go-securesystemslib cosign#1141
2. Remove fuzzing check - unsupported go-fuzz cosign#1020
3. Included timeout option for uploading to Rekor cosign#1001
4. Fixed modtime for reproducible goreleaser cosign#971
5. Included trimpath in goreleaser cosign#968
6. Reproducible builds with trimpath cosign#944
7. Feat - Included the golanglint-ci to be downloaded cosign#124
8. Feat - Included static binary in go build cosign#121
9. Feat- Enable dependabot settings cosign#120
10. Create codeql-analysis.yml cosign#119

Issues in cosign

https://github.com/sigstore/cosign/issues?q=is%3Aissue+author%3Anaveensrinivasan+

PR's rekor

https://github.com/sigstore/rekor/pulls?q=author%3Anaveensrinivasan

Issues in rekor

https://github.com/sigstore/rekor/issues?q=author%3Anaveensrinivasan

cc @lukehinds @dlorenc @bobcallaway

[lukehinds]

We don't have anything defined as each project has autonomy to manage its own maintainers (codeowners).

As a general guide, I myself view a maintainer as someone who regularly helps review code, finds and resolves bugs and adds features. A good candidate is someone who has a consistent presence in the project.

I hope that helps and sorry for not being more specific. Currently a lot of your contributions (of a varied type) are towards cosign, so that looks like a good trajectory towards being a maintainer.

[naveensrinivasan]

Good to know. Thanks,I would like and being interested in becoming a maintainer now.

[dlorenc]

I kind of miss having something like peribolos to manage permissions across an org, but don't really want to have to setup prow just for that. @cpanato do you know of any way to do that easier?

[cpanato]

I kind of miss having something like peribolos to manage permissions across an org, but don't really want to have to setup prow just for that. @cpanato do you know of any way to do that easier?

I did this: https://github.com/cpanato/pulumi-github-sync and implemented it at mattermost, it is working just fine and easy to deploy and get those up and running

[dlorenc]

Nice! do you think we can give it a try on one project? Cosign could use this as a start.

[cpanato]

yes! can we create a new repo that I can push the code and set up? can we don't need to connect to the pulumi UI, we can use GCP Storage as the state storage

I will ping you in the sigstore slack

[dlorenc]

Thanks!

I realize this doesn't solve the actual contributor ladder problem, but it at least makes it so the mechanics of joining as a contributor are clearly defined and transparent. We can figure out the hard part next :)

[naveensrinivasan]

yes! can we create a new repo that I can push the code and set up? can we don't need to connect to the pulumi UI, we can use GCP Storage as the state storage

I will ping you in the sigstore slack

Pulumi is cool. But the stack would be in a personal Pulumi account and cannot be shared amongst members unless a paid account.

How is this going to be handled?

[cpanato]

we will not use the pulumi account, we will store the state in the gcp storage, we will miss some nice features, but that will work fine for us

[justaugustus]

I realize this doesn't solve the actual contributor ladder problem

@dlorenc -- Indeed! Could we move this discussion to sigstore/community#53?

---

As for a contributor ladder and some context, I opened a similar issue to this a little while ago in scorecard: ossf/scorecard#1529

I haven't "figured it out" just yet, but some suggestions I'll make around it, based on previous experiences/systems/orgs I currently work in (stares at kubernetes)...

• Lightweight or heavyweight, make sure the decisions are discussed and documented: https://github.com/kubernetes/community/blob/master/github-management/new-membership-procedure.md
• At least two sponsors (at least one of which is not an employee of the candidate's): https://github.com/kubernetes/community/blob/master/github-management/new-membership-procedure.md#sponsor-requirements
• Org membership should be a low bar, elevated privileges come with higher requirements: https://github.com/kubernetes/community/blob/master/community-membership.md
• Make changes visible/auditable (non-org members cannot see behind the scenes without this): https://github.com/sigstore/sigstore/issues/308 / https://github.com/relengfam/peribolos / https://github.com/kubernetes/org
• Actively probe for changes to membership... promote or prune people based on their activity; don't wait for them to ask you (because some folks are shy/may not think they deserve it)
• Policy is living and should be actively reviewed/improved
• Contributing is NOT code; ensure you have workflows/incentives for non-code contributors: https://github.com/kubernetes/community/blob/master/contributors/guide/non-code-contributions.md

I've linked a bunch from Kubernetes, but I'd be remiss if I didn't call out the CNCF TAG Contributor Strategy body of work, a lot of which we drew from our experiences in Kubernetes and other OSS communities: https://contribute.cncf.io/maintainers/

[cpanato]

i was speaking with Dan to re-use some docs/process from he k8s :D

[justaugustus]

i was speaking with Dan to re-use some docs/process from he k8s :D

Feel free to tag me for reviews, as this is something I'm planning to do for scorecard and friends and hopefully something lightweight/generic enough to use for all of OpenSSF.

[justaugustus]

w.r.t. contributing guides, I'm in the midst of rewriting the one for Kubernetes SIG Release, which I think is coming along pretty nicely: kubernetes/sig-release#1862

[justaugustus]

In terms of actually operationalizing this request, what I'd likely do is approve, add @naveensrinivasan to the org, create a team for triagers/reviewers, and give that team triage permissions on the requisite repos.

triage is a nice middleground between no/read access and destructive actions.

[dlorenc]

In terms of actually operationalizing this request, what I'd likely do is approve, add @naveensrinivasan to the org, create a team for triagers/reviewers, and give that team triage permissions on the requisite repos.

+1, approve!

[lukehinds]

In terms of actually operationalizing this request, what I'd likely do is approve, add @naveensrinivasan to the org, create a team for triagers/reviewers, and give that team triage permissions on the requisite repos.

triage is a nice middleground between no/read access and destructive actions.

I like this as well. That way contributors can first go to triage and we bring on new codeowners when there is a real need (lack of reviewers who can merge). This way we can have people recognised and have some ability to help out with housekeeping, but we don't end up with large codeowner grants.

[naveensrinivasan]

In terms of actually operationalizing this request, what I'd likely do is approve, add @naveensrinivasan to the org, create a team for triagers/reviewers, and give that team triage permissions on the requisite repos.
triage is a nice middleground between no/read access and destructive actions.

I like this as well. That way contributors can first go to triage and we bring on new codeowners when there is a real need (lack of reviewers who can merge). This way we can have people recognised and have some ability to help out with housekeeping, but we don't end up with large codeowner grants.

Friendly ping!

[dlorenc]

Invite sent!

[dlorenc]

Reopening to track the rest of the ladder process :)

[lukehinds]

Does this mean @naveensrinivasan (or whoever we add) has triage over all projects in the org, or just sigstore/sigstore?

[dlorenc]

Just sigstore/sigstore

[cpanato]

I'm going to work on the docs this week

[lukehinds]

closing as now tracked in sigstore/community#54