Skip to content
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

Expand contributor criteria? #413

Open
stevenhorsman opened this issue Oct 22, 2024 · 1 comment
Open

Expand contributor criteria? #413

stevenhorsman opened this issue Oct 22, 2024 · 1 comment
Labels
enhancement Improvement to an existing feature needs-review Needs to be assessed by the team.

Comments

@stevenhorsman
Copy link
Member

stevenhorsman commented Oct 22, 2024

At the moment the contributor criteria states:

A Contributor to the Kata Containers project is someone who has had code merged within the last 12 months.

This is used to determine AC voting eligibility and could in future also be used to assess whether developers remain on the committer list.

We had some discussion on the vPTG about this and pointed out that in theory we could have someone who does many, many high quality reviews, but doesn't develop code, so have any commits, and would currently not be seen as active.

We might not have anyone that falls into this gap, but there are a number of things we can consider:

  1. If we formally changed the criteria to be anyone who has made a merged commit, or a review in the last 12 months then it means that someone could maintain their active status with a low-quality review (such as just adding an approval to a PR that already has multiple approvers) every 11 months, so that might be going too far the other way (being active by doing something that could be trivially scripted).
  2. Adding some sort of threshold for reviews, so expected 1 commit, or 5/10 reviews. Again this could be scripted fairly easily
  3. Staying as we are, but adding human discretion. At the moment our election process has a step

    Generate an initial electorate list and share it with the AC and community to ensure that the list contains all active contributors
    so the list of active contributors (based on commits, not reviews) is published twice a year and people asked to review it. We could formalise that somebody with no commits, but a history of contributions (design, reviews, CI infra maintenance etc) could apply to the AC for the right to be considered an active contributor and the AC could vote on whether to accept this.

  4. Stay as we are and not accept reviews as active contribution. It's likely that not many people would be valuable reviewers, but not have any code commits in a 12 month period as AFAIK we've yet to have someone complain that they were missed off the voters list, so we could just stay as we are.
@stevenhorsman stevenhorsman added enhancement Improvement to an existing feature needs-review Needs to be assessed by the team. labels Oct 22, 2024
@stevenhorsman
Copy link
Member Author

My personal opinion is that approach 3 is probably the best approach as in enforces transparency and human discretion in edge cases, but I understand that it might be best to have a clear rule and let a computer decide who matches that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement to an existing feature needs-review Needs to be assessed by the team.
Projects
None yet
Development

No branches or pull requests

1 participant