Vote in new maintainer volunteers for distribution-spec

[caniszczyk]

We've had a great set of active volunteers to become maintainers on the distribution spec:

The next step in the process after the call for volunteers is to initiate a PR and vote by the existing @opencontainers/distribution-spec-maintainers to add them as official maintainers, this will be done on a one by one basis: https://github.com/opencontainers/distribution-spec/blob/main/MAINTAINERS

[caniszczyk]

All the votes for the volunteers have been kicked off:

https://github.com/opencontainers/distribution-spec/pull/267 https://github.com/opencontainers/distribution-spec/pull/268 https://github.com/opencontainers/distribution-spec/pull/269 https://github.com/opencontainers/distribution-spec/pull/270 https://github.com/opencontainers/distribution-spec/pull/271

The @opencontainers/distribution-spec-maintainers will just need to provide LGTMs in the coming week

[vbatts]

hrm, this seems a confusing format :thinking:

[vbatts]

sorry, i'm just pondering on the voting logistics. If maintainers get a 2/3 approval, then their addition would shift the votes needed for other's 2/3 approval. Also, I'm curious if there is a particular goal for number of maintainers for distribution-spec, as the current maintainers are already active.

[caniszczyk]

@vbatts I figured it was fairer than doing all at once, we can leave things open for a week and close them all the same time (if everyone passes)

[dmcgowan]

I am voting to reject all the new maintainers at this time. These are my reasons:

• each candidate deserves to be considered individually rather than as a group
• the distribution-spec does not have an issue with inactive maintainers which requires such an intervention
• making a large change which impacts voting right before release 1.0 is not a good idea in my view

I look forward to discussing each candidate and proposing them individually after we finish the 1.0 release. Having a dedicated group of maintainers who are focused on preserving the stability of 1.x is important and I am happy to have those discussions about bringing individuals in. Normally maintainers will have time to discuss candidates before opening a PR to add them into the maintainers file. This allows maintainers to have conversations with candidates about what the maintainer expectations are and when it is a good time to become a maintainer. This prevents maintainers from having to openly reject candidates when the timing or fit just isn't there yet. In this case, I don't think it is fair to accept some and reject others, so I am rejecting not based on any individual, but on the process.

[jonjohnsonjr]

we can leave things open for a week

Any objection to closing PRs 267-271? I agree with @dmcgowan that the distribution-spec doesn't need any kind of intervention.

[vbatts]

closing for now