Please nominate candidates correctly

[Josh Berkus]

Fellow contributors:

Per the voter guide, in order for your nomination endorsements to count, the Election committee needs two pieces of information in your email:

1. Your company affiliation, if it is not clearly indicated by your email domain;

2. your Github handle, so that we can verify that you are a voter.

A naked "+1" without any of this information will result in the candidate not being nominated.

[Benjamin Elder]

Interesting, thanks Josh ... does devstats data not cover both of these points (affiliation, email, github association)?

If our GitHub handle is @foo and our email is f...@company.com, do we still need to list our github handle?

Others: for reference the written documentation is here: https://github.com/kubernetes/community/tree/master/events/elections/2020#candidacy-process

Additionally this documentation states:

> When a candidate has reached the necessary three endorsements, one of the Election Officers will announce that on the email thread. After that, please do not endorse the candidate further.

This seems counter-productive. Intended or not, people are using these threads to voice their support beyond the strict requirements.

[Tim Pepper]

In the past nominations took the form of a PR to the election directory of the repo.  If we return to that (eg: email once “here’s my PR…comment there”) people can comment and +1 and emoji and whatnot, their comments are linked to their GitHub id, the election officers can track the lgtm’s, approve, and merge and then repo’s merged state will come to reflect the valid candidacies.  Feels like that would streamline.

 

-- 

Tim Pepper

Orchestration Lead

VMware Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOZRXm8w9QPMcB78Yu5jM7yk7Qiiqit_r9R0qGxMiOCwVuxe%3Dg%40mail.gmail.com.

[Josh Berkus]

On 8/14/20 9:50 AM, Benjamin Elder wrote:
> Interesting, thanks Josh ... does devstats data not cover both of these
> points (affiliation, email, github association)?
>
> If our GitHub handle is @foo and our email is f...@company.com

> <mailto:f...@company.com>, do we still need to list our github handle?

That's asking the EC to do a lot of extra work looking you up. There's
only 3 of us, and we're doing this in our spare time. Email
associations with GH handles are far from solid, as will be demonstrated
when we start mailing out ballots.

Please put your specific GH handle in the email body.

> Others: for reference the written documentation is
> here: https://github.com/kubernetes/community/tree/master/events/elections/2020#candidacy-process
>
> Additionally this documentation states:
>
>> When a candidate has reached the necessary three endorsements, one of
> the Election Officers will announce that on the email thread. After
> that, please do not endorse the candidate further.
>
> This seems counter-productive. Intended or not, people are using these
> threads to voice their support beyond the strict requirements.

This was a demand of the Steering Committee. If you find it
counterproductive, please address that to them.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

[Benjamin Elder]

Fair, thanks!

[Josh Berkus]

On 8/14/20 9:53 AM, Tim Pepper wrote:
> In the past nominations took the form of a PR to the election directory
> of the repo.  If we return to that (eg: email once “here’s my PR…comment
> there”) people can comment and +1 and emoji and whatnot, their comments
> are linked to their GitHub id, the election officers can track the
> lgtm’s, approve, and merge and then repo’s merged state will come to
> reflect the valid candidacies.  Feels like that would streamline.

Agreed. However, that idea was not introduced to the current EC until
the day before nominations opened; all of the existing documentation on
how to run an election center on kdev. At that point, a change in
process would have required delaying the election by 2 weeks.

I'm hoping that by next year we will have an app that allows folks to
log in with their GH login directly, and then we won't be doing manual
tracking at all. We're working with Community Bridge to make this a
project.