PROCESS CHANGE: Determine who is eligible to vote in elections

[lance]

While updating ROLES.md, there was some discussion around the requirements for voting eligibility. See: https://github.com/knative/community/pull/1343#discussion_r1198717313

This issue has been separated out from that PR so that it can be discussed and resolved separately and not hold up the changes to ROLES.md.

/kind proposal

/assign @geekygirldawn

[geekygirldawn]

As @lance mentioned, there was some discussion in the ROLES PR about changing the rules about who can vote in Knative elections.

Right now, we have 58 people who are eligible to vote using the current criteria: 50 contributions in devstats or sitting on an existing committee (SC, TC, TOC).

If as @nainaz suggested, we dropped that to 25 contributions in devstats, we would have ~75 people eligible to vote, so not a big increase. Here is the devstats data

One suggestion was to use membership in knative / knative sandbox as the criteria for voting. Right now, we have ~135 people who are org members or org admins in those 2 orgs, but I'm not sure if all of them are really still active in the project?

The advantage of using devstats is that you know that the eligible voters are still active in the project, and we have an exception process that allows for people making other contributions to be eligible. The downside is that people who aren't eligible because they make other non-GitHub contributions might feel like they don't deserve to vote and not bother submitting an exception request.

The advantage of using org membership is that it's more consistent with how the project operates on a day to day basis and allows people to continue to vote in all elections even if their contributions are a bit bursty and they might not always meet the criteria. The downside is that there is the possibility that non-active community members might continue to vote.

And it's not necessarily a one or the other decision. We could choose to make org members always eligible (like we do now with SC, TOC, and TC) and also anyone with a certain number of contributions in devstats.

Ultimately, any decision about changes to the voting criteria lie with the @knative/steering-committee but I wanted to kick off the discussion with some data and options for people to think about.

cc: @evankanderson @jberkus

[lance]

The downside is that there is the possibility that non-active community members might continue to vote.

Overall, this seems like a fairly minor downside in my opinion. If org members are not active, it's highly unlikely that they will be voting. I suppose it does open a slight opportunity for malicious folks to exploit, but even that seems like an unlikely outcome.

[geekygirldawn]

The downside is that there is the possibility that non-active community members might continue to vote.

Overall, this seems like a fairly minor downside in my opinion. If org members are not active, it's highly unlikely that they will be voting. I suppose it does open a slight opportunity for malicious folks to exploit, but even that seems like an unlikely outcome.

Agreed. It's something to think about, but I don't see it as being likely to cause any issues.

[evankanderson]

How much work is it to collect the names from devstats? I have a slight preference for that mechanism and making org membership be "if you want it", rather than needing to manage it more actively.

On the other hand, if we're already managing the org membership proactively, then maybe that's less work than also needing to pull out contribution statistics.

Basically, my preference is for low overhead, with a slight additional preference for rules that require less overall overhead to administer.

Perhaps we could split the difference and have N contributions as a default bar for org membership.

[geekygirldawn]

How much work is it to collect the names from devstats? I have a slight preference for that mechanism and making org membership be "if you want it", rather than needing to manage it more actively.

Pulling the data from devstats is trivial - it's a matter of copying the gh id's and converting them to a yaml voters file. Since the org data is also in yaml, it would be trivial to get the data from there, too. So neither option is really any significant amount of work. Since it's easy either way, I think it's better to approach this as a decision about what would be best for the Knative project with an eye toward thinking about how we can get people more engaged.

[nainaz]

I agree with Lance that it will be a fairly minor downside. I also would like to add that if a person is not eligible, it is intimidating to go and file an exception request as you need to justify as well as you think since you are not eligible, oh well, you aren't and go your merry way.

Since we are looking for more contributors, we are also looking for more engagement in the community and I think this could be a first step. Thank you, -N

On Mon, 22 May 2023 at 11:08, Dawn Foster @.***> wrote:

How much work is it to collect the names from devstats? I have a slight preference for that mechanism and making org membership be "if you want it", rather than needing to manage it more actively.

Pulling the data from devstats is trivial - it's a matter of copying the gh id's and converting them to a yaml voters file. Since the org data is also in yaml, it would be trivial to get the data from there, too. So neither option is really any significant amount of work. Since it's easy either way, I think it's better to approach this as a decision about what would be best for the Knative project with an eye toward thinking about how we can get people more engaged.

— Reply to this email directly, view it on GitHub https://github.com/knative/community/issues/1350#issuecomment-1557394834, or unsubscribe https://github.com/notifications/unsubscribe-auth/AISZCFAPJN5LD3K6BGJPQGLXHN6P7ANCNFSM6AAAAAAYH2VGLA . You are receiving this because you were mentioned.Message ID: @.***>

[lance]

I also would like to add that if a person is not eligible, it is intimidating to go and file an exception request

This is a concern, imo, and could be a barrier for folks. I would like to make it easy to be involved and active, if possible, without adding any overhead or risk to what we are doing today.