Linux Foundation Technical Advisory Board Elections -- Change to charter

Linux Foundation Technical Advisory Board Elections -- Change to charter

[Laura Abbott]

On behalf of the Linux Foundation Technical Advisory Board (TAB), I
would like to announce the following changes to our charter, available
at https://wiki.linuxfoundation.org/tab/start

- Line 2b that previously read "All members shall be elected by a vote
amongst all invitees of the Linux Kernel Summit." is changed to "All
members shall be elected by a vote amongst all attendees of the Linux
Kernel Summit."

This clarifies that kernel summit is no longer invite only.

- Under meetings and membership, the following line is added
"The TAB, at its discretion, may set criteria to allow for absentee
voting for those who are unable to attend the Linux Kernel Summit."

For those who like diff form, this looks like

diff --git a/charter b/charter
index 45816d7..70b2e56 100644
--- a/charter
+++ b/charter
@@ -4,7 +4,8 @@
      - Promote and Support the programmes with which the TAB is charged 
to the wider Linux and Open Source Communities.
    - Meetings and Membership.
      - The TAB consists of ten voting members.
-    - All members shall be elected by a vote amongst all invitees of 
the Linux Kernel Summit.
+    - All members shall be elected by a vote amongst all attendees of 
the Linux Kernel Summit.
+    - The TAB, at its discretion, may set criteria to allow for 
absentee voting for those who are unable to attend the Linux Kernel Summit.
      - Self nominations for the election shall be accepted from any 
person, via email to the TAB mailing list, up until the time of the 
election.
      - Membership of the TAB shall be for a term of 2 years with 
staggered 1-year elections.
      - The TAB shall elect a Chair and Vice-Chair of the TAB from 
amongst their members to serve a renewable 1 year term.


This change is intended to be a follow on to last year's changes to vote
electronically instead of using paper ballots
(see 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-July/006582.html)
We will be announcing criteria for absentee voting at a later date.

If you have any questions, feel free to speak up here or privately at
tab@lists.linuxfoundation.org.

Thanks,
Laura

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Laurent Pinchart]

Hi Laura,

On Wed, Mar 11, 2020 at 08:19:46PM -0400, Laura Abbott wrote:
> On behalf of the Linux Foundation Technical Advisory Board (TAB), I
> would like to announce the following changes to our charter, available
> at https://wiki.linuxfoundation.org/tab/start
> 
> - Line 2b that previously read "All members shall be elected by a vote
> amongst all invitees of the Linux Kernel Summit." is changed to "All
> members shall be elected by a vote amongst all attendees of the Linux
> Kernel Summit."
> 
> This clarifies that kernel summit is no longer invite only.

This is a good clarification, no issue with it.

> - Under meetings and membership, the following line is added
> "The TAB, at its discretion, may set criteria to allow for absentee
> voting for those who are unable to attend the Linux Kernel Summit."

This is however a bit more problematic. I understand the intent, which I
believe is good, but it would make ballot stuffing very easy. At the
same time I understood it will not be an easy task to set clear written
rules that wouldn't be over complex and would still allow reaching the
end goal of expanding the election to the whole community through
electronic voting. I'm afraid I don't have a solution to propose to this
problem at this time.

> For those who like diff form, this looks like
> 
> diff --git a/charter b/charter
> index 45816d7..70b2e56 100644
> --- a/charter
> +++ b/charter
> @@ -4,7 +4,8 @@
>       - Promote and Support the programmes with which the TAB is charged 
> to the wider Linux and Open Source Communities.
>     - Meetings and Membership.
>       - The TAB consists of ten voting members.
> -    - All members shall be elected by a vote amongst all invitees of 
> the Linux Kernel Summit.
> +    - All members shall be elected by a vote amongst all attendees of 
> the Linux Kernel Summit.
> +    - The TAB, at its discretion, may set criteria to allow for 
> absentee voting for those who are unable to attend the Linux Kernel Summit.
>       - Self nominations for the election shall be accepted from any 
> person, via email to the TAB mailing list, up until the time of the 
> election.
>       - Membership of the TAB shall be for a term of 2 years with 
> staggered 1-year elections.
>       - The TAB shall elect a Chair and Vice-Chair of the TAB from 
> amongst their members to serve a renewable 1 year term.
> 
> 
> This change is intended to be a follow on to last year's changes to vote
> electronically instead of using paper ballots
> (see 
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-July/006582.html)
> We will be announcing criteria for absentee voting at a later date.
> 
> If you have any questions, feel free to speak up here or privately at
> tab@lists.linuxfoundation.org.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Laura Abbott]

(speaking only for myself)

On 3/11/20 8:34 PM, Laurent Pinchart wrote:
> Hi Laura,
> 
> On Wed, Mar 11, 2020 at 08:19:46PM -0400, Laura Abbott wrote:
>> On behalf of the Linux Foundation Technical Advisory Board (TAB), I
>> would like to announce the following changes to our charter, available
>> at https://wiki.linuxfoundation.org/tab/start
>>
>> - Line 2b that previously read "All members shall be elected by a vote
>> amongst all invitees of the Linux Kernel Summit." is changed to "All
>> members shall be elected by a vote amongst all attendees of the Linux
>> Kernel Summit."
>>
>> This clarifies that kernel summit is no longer invite only.
> 
> This is a good clarification, no issue with it.
> 
>> - Under meetings and membership, the following line is added
>> "The TAB, at its discretion, may set criteria to allow for absentee
>> voting for those who are unable to attend the Linux Kernel Summit."
> 
> This is however a bit more problematic. I understand the intent, which I
> believe is good, but it would make ballot stuffing very easy. At the
> same time I understood it will not be an easy task to set clear written
> rules that wouldn't be over complex and would still allow reaching the
> end goal of expanding the election to the whole community through
> electronic voting. I'm afraid I don't have a solution to propose to this
> problem at this time.
> 

Thanks for the feedback.

Yes, this is a lot of the discussion we've been having. This is
definitely something we are carefully considering and intend to work
through. I, personally, want to err on the side of letting more
people participate but it's very hard to figure out what's a realistic
threat model. The TAB has a charter but it only works because the
community trusts us. If we were to get vote flooded by 10000 sock
puppets and elect 5 people who the majority of the community doesn't
trust, what impact could they actually have?

The charter also has this line: "The TAB is being formed at the
discretion of the Board. The Board alone may decide to terminate the TAB
in its sole discretion; provided however, that the Board or its
authorized officer shall first consult the TAB Chair." So in theory,
the TAB could be abolished. Would this actually happen? I would
really hope not but it's worth pointing out that there is a possible
solution for election edge cases, even if it's a very destructive one.
On the other hand, maybe I've actually provided a stronger argument for
why we really need to be careful about avoiding ballot box stuffing
if the only option is to burn it all down.

Also in case anyone in the community is worried we're trying to rush
this through in case of conference cancellations, this (really) has
been in discussion for the past few months. The way this is change is
worded the TAB also has the option of not allowing absentee voting, so
if in the unlikely event we don't come up with acceptable terms we will
be going with the existing voting procedures and not allowing absentee
voting.

Thanks,
Laura

>> For those who like diff form, this looks like
>>
>> diff --git a/charter b/charter
>> index 45816d7..70b2e56 100644
>> --- a/charter
>> +++ b/charter
>> @@ -4,7 +4,8 @@
>>        - Promote and Support the programmes with which the TAB is charged
>> to the wider Linux and Open Source Communities.
>>      - Meetings and Membership.
>>        - The TAB consists of ten voting members.
>> -    - All members shall be elected by a vote amongst all invitees of
>> the Linux Kernel Summit.
>> +    - All members shall be elected by a vote amongst all attendees of
>> the Linux Kernel Summit.
>> +    - The TAB, at its discretion, may set criteria to allow for
>> absentee voting for those who are unable to attend the Linux Kernel Summit.
>>        - Self nominations for the election shall be accepted from any
>> person, via email to the TAB mailing list, up until the time of the
>> election.
>>        - Membership of the TAB shall be for a term of 2 years with
>> staggered 1-year elections.
>>        - The TAB shall elect a Chair and Vice-Chair of the TAB from
>> amongst their members to serve a renewable 1 year term.
>>
>>
>> This change is intended to be a follow on to last year's changes to vote
>> electronically instead of using paper ballots
>> (see
>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-July/006582.html)
>> We will be announcing criteria for absentee voting at a later date.
>>
>> If you have any questions, feel free to speak up here or privately at
>> tab@lists.linuxfoundation.org.
> 

RE: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Bird, Tim]

> -----Original Message-----
> From:  Laurent Pinchart
> 
> Hi Laura,
> 
> On Wed, Mar 11, 2020 at 08:19:46PM -0400, Laura Abbott wrote:
> > On behalf of the Linux Foundation Technical Advisory Board (TAB), I
> > would like to announce the following changes to our charter, available
> > at https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.linuxfoundation.org_tab_start&d=DwICAg&c=fP4tf--
> 1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-INWqfY8MsF0&m=rEcpcrRVZ-R-
> msxXCoATt2eqeJ0slEmwjZvSIsW2FnA&s=uCuhAV3NJJQ8ZD7FRbWtcW1p_3-DDKj2EsqssXv_hm0&e=
> >
> > - Line 2b that previously read "All members shall be elected by a vote
> > amongst all invitees of the Linux Kernel Summit." is changed to "All
> > members shall be elected by a vote amongst all attendees of the Linux
> > Kernel Summit."
> >
> > This clarifies that kernel summit is no longer invite only.
> 
> This is a good clarification, no issue with it.
> 
> > - Under meetings and membership, the following line is added
> > "The TAB, at its discretion, may set criteria to allow for absentee
> > voting for those who are unable to attend the Linux Kernel Summit."
> 
> This is however a bit more problematic. I understand the intent, which I
> believe is good, but it would make ballot stuffing very easy. At the
> same time I understood it will not be an easy task to set clear written
> rules that wouldn't be over complex and would still allow reaching the
> end goal of expanding the election to the whole community through
> electronic voting. I'm afraid I don't have a solution to propose to this
> problem at this time.

I agree with Laurent.  I'm not sure how to solve this problem, but
I think you need something to indicate the voter approval policy
besides "the TAB will decide it, and can change it when they like".

I suppose the pool of voters has been decided historically by the Kernel
Summit invitation committee.  Some randomness was introduced by
allowing voting by attendees from whatever event the Linux Foundation
co-located with the Kernel Summit.  I think in practical terms,
this means that recently the voting pool was self-selected (somewhat), but
was skewed towards people who could travel, or had employer support.
But in any event, the selection of the voting pool was done by people outside
the TAB (or at least not necessarily inside the TAB), and without any eye towards
skewing the election results.  That is, I don't think the kernel summit invitation
committee, or the LF event staff, ever considered TAB voting in their KS attendee
selection or event pairing choices.

I don't think that the current TAB would do anything wacky here.  And I suspect
it's probably not a huge concern even for future TABs whose constitution we don't
know yet. I do think, however, it would be better to have a written policy
for the voting eligibility, that the TAB members can't change on a whim.
 -- Tim
 
> 
> > For those who like diff form, this looks like
> >
> > diff --git a/charter b/charter
> > index 45816d7..70b2e56 100644
> > --- a/charter
> > +++ b/charter
> > @@ -4,7 +4,8 @@
> >       - Promote and Support the programmes with which the TAB is charged
> > to the wider Linux and Open Source Communities.
> >     - Meetings and Membership.
> >       - The TAB consists of ten voting members.
> > -    - All members shall be elected by a vote amongst all invitees of
> > the Linux Kernel Summit.
> > +    - All members shall be elected by a vote amongst all attendees of
> > the Linux Kernel Summit.
> > +    - The TAB, at its discretion, may set criteria to allow for
> > absentee voting for those who are unable to attend the Linux Kernel Summit.
> >       - Self nominations for the election shall be accepted from any
> > person, via email to the TAB mailing list, up until the time of the
> > election.
> >       - Membership of the TAB shall be for a term of 2 years with
> > staggered 1-year elections.
> >       - The TAB shall elect a Chair and Vice-Chair of the TAB from
> > amongst their members to serve a renewable 1 year term.
> >
> >
> > This change is intended to be a follow on to last year's changes to vote
> > electronically instead of using paper ballots
> > (see
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linuxfoundation.org_pipermail_ksummit-2Ddiscuss_2019-
> 2DJuly_006582.html&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> INWqfY8MsF0&m=rEcpcrRVZ-R-msxXCoATt2eqeJ0slEmwjZvSIsW2FnA&s=Kdo5ehAJ9pXNz1IVeBciY9CqASsXZ_Ai8NLdSajpDcA&e= )
> > We will be announcing criteria for absentee voting at a later date.
> >
> > If you have any questions, feel free to speak up here or privately at
> > tab@lists.linuxfoundation.org.
> 
> --
> Regards,
> 
> Laurent Pinchart
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linuxfoundation.org_mailman_listinfo_ksummit-
> 2Ddiscuss&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> INWqfY8MsF0&m=rEcpcrRVZ-R-msxXCoATt2eqeJ0slEmwjZvSIsW2FnA&s=ITok8MjtzP2G4P-KjwsfV4Ohz0qxG-mPu4S8eVf15sA&e=

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Laura Abbott]

On 3/12/20 5:28 PM, Bird, Tim wrote:
>> -----Original Message-----
>> From:  Laurent Pinchart
>>
>> Hi Laura,
>>
>> On Wed, Mar 11, 2020 at 08:19:46PM -0400, Laura Abbott wrote:
>>> On behalf of the Linux Foundation Technical Advisory Board (TAB), I
>>> would like to announce the following changes to our charter, available
>>> at https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.linuxfoundation.org_tab_start&d=DwICAg&c=fP4tf--
>> 1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-INWqfY8MsF0&m=rEcpcrRVZ-R-
>> msxXCoATt2eqeJ0slEmwjZvSIsW2FnA&s=uCuhAV3NJJQ8ZD7FRbWtcW1p_3-DDKj2EsqssXv_hm0&e=
>>>
>>> - Line 2b that previously read "All members shall be elected by a vote
>>> amongst all invitees of the Linux Kernel Summit." is changed to "All
>>> members shall be elected by a vote amongst all attendees of the Linux
>>> Kernel Summit."
>>>
>>> This clarifies that kernel summit is no longer invite only.
>>
>> This is a good clarification, no issue with it.
>>
>>> - Under meetings and membership, the following line is added
>>> "The TAB, at its discretion, may set criteria to allow for absentee
>>> voting for those who are unable to attend the Linux Kernel Summit."
>>
>> This is however a bit more problematic. I understand the intent, which I
>> believe is good, but it would make ballot stuffing very easy. At the
>> same time I understood it will not be an easy task to set clear written
>> rules that wouldn't be over complex and would still allow reaching the
>> end goal of expanding the election to the whole community through
>> electronic voting. I'm afraid I don't have a solution to propose to this
>> problem at this time.
> 
> I agree with Laurent.  I'm not sure how to solve this problem, but
> I think you need something to indicate the voter approval policy
> besides "the TAB will decide it, and can change it when they like".
> 
> I suppose the pool of voters has been decided historically by the Kernel
> Summit invitation committee.  Some randomness was introduced by
> allowing voting by attendees from whatever event the Linux Foundation
> co-located with the Kernel Summit.  I think in practical terms,
> this means that recently the voting pool was self-selected (somewhat), but
> was skewed towards people who could travel, or had employer support.
> But in any event, the selection of the voting pool was done by people outside
> the TAB (or at least not necessarily inside the TAB), and without any eye towards
> skewing the election results.  That is, I don't think the kernel summit invitation
> committee, or the LF event staff, ever considered TAB voting in their KS attendee
> selection or event pairing choices.
> 
> I don't think that the current TAB would do anything wacky here.  And I suspect
> it's probably not a huge concern even for future TABs whose constitution we don't
> know yet. I do think, however, it would be better to have a written policy
> for the voting eligibility, that the TAB members can't change on a whim.
>   -- Tim
>   

(my own opinion again)

We intentionally wanted to keep it vague to avoid having to change the
charter every time we wanted to tweak the absentee voting requirements.
This is because while everyone is in favor of absentee voting in theory
there were concerns about trying to get the numbers right.

I'd argue that the way the charter is currently written the TAB
members can really change the election on a whim. The wording "All
members shall be elected by a vote amongst all invitees of the Linux
Kernel Summit" basically says nothing about how the vote is conducted.
The TAB does run the election and the community has trusted that we
set up proctors who aren't up for election and that we are using a
voting procedure that is actually fair as opposed to, say, voting
proportional to lines of code removed last year. I don't think this
is necessarily a _good_ situation since it could be easily abused
but I also think that absentee voting falls into the same category
of trusting the TAB to not come up with some arbitrary voting method
designed to get the outcome they want.

Maybe the real question is if the community would rather see all
election procedures specified explicitly rather than just placing
trust in the TAB.

Thanks,
Laura

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Theodore Y. Ts'o]

On Thu, Mar 12, 2020 at 09:28:09PM +0000, Bird, Tim wrote:
> I agree with Laurent.  I'm not sure how to solve this problem, but
> I think you need something to indicate the voter approval policy
> besides "the TAB will decide it, and can change it when they like".
> 
> I suppose the pool of voters has been decided historically by the Kernel
> Summit invitation committee.  Some randomness was introduced by
> allowing voting by attendees from whatever event the Linux Foundation
> co-located with the Kernel Summit.  I think in practical terms,
> this means that recently the voting pool was self-selected (somewhat), but
> was skewed towards people who could travel, or had employer support.
> But in any event, the selection of the voting pool was done by people outside
> the TAB (or at least not necessarily inside the TAB), and without any eye towards
> skewing the election results.  That is, I don't think the kernel summit invitation
> committee, or the LF event staff, ever considered TAB voting in their KS attendee
> selection or event pairing choices.

(Speaking personally for myself)

The choice to include whatever LF event the Kernel Summit was
colocated with was a choice that was made by the TAB on an ad-hoc
basis.  There is nothing about that in the TAB charter at all.  So
we've *already* been doing things in a way that is not consistent with
TAB charter --- for years and years.

Starting last year, we experimented with electronic voting.  We didn't
change the composition of who could vote (it was anyone attending
Plumbers), but one of the reasons was that we didn't want to change
two variables at once.

We haven't made any final decisions yet about how the pool of voters
might be expanded.  But it might include (for example) people who have
user accounts on kernel.org.  Or historically, one of the pools from
which the kernel summitte attendee list would be drawn included
everyone who at least N Signed-off-by:, Reviewed-by:, etc.  Since
there was a Kernel Summit program committee filtering who got invites
(and there was non-trivial overlap between the program committee and
the TAB), in theory that very much could influence the TAB elections.
Expanding the pool to those who were interested and who were attending
the colocated event very much decreased that effect, but there has
always been a human filtering element.

One of the potential failures that having a human filtering element
prevents is the Sad/Rabid Puppies scenario:

https://slate.com/culture/2016/04/sad-and-rabid-puppies-are-trying-to-game-the-hugo-award-shortlists-again-in-2016.html

So for example, if we set some rule like, a single Signed-off-by: is
enough to get a vote, what would happen over a few months, a thousand
spelling/whitespace "trivial" patches, all from different sock puppet
accounts, show up and get absorbed into the tree?  With a human
program committee, it's easy for humans to say, "Ha, ha.  No."  But if
we use a mechnical rule, and badly chosen criteria, it might be really
easy for some mischief makers to carry out a Sad Puppies style attack
on the voting system.

On the flip side, having humans deciding who can and can't vote has
other really bad effects regarding the election's legitimacy.  It
worked 5+ years ago, because it was simpler times, and the formal
reason for the selection was attendance to a closed technical meeting,
and we later decided to hang the TAB elections off of it.

So that means we need to be smart about how we pick the criteria.
Using a kernel.org account might be a good approach, since it would be
a lot harder for a huge number of sock puppet accounts to meet that
criteria.  We don't have a final proposal for something which can be
objectively measured, but can't be easily gamed by someone who is
trying to subvert the system.  It is pretty clear, though, that we
need to have that clearly articulated, in writing, *before* we start
the nomination for the next round of TAB candidates.

I will also point out that we may not have much of a choice about
switching to something besides "people who attend the colocated event
where the Kernel Summit is held".  The program/organizing committees
for LPC, KS, and MS, are continuing to make plans in the hope that the
COVID-19 pandemic will have subsided enough that it will be safe to
hold an conference of 400-500 people in Halifax.  However, nobody
knows if that is the case.  If you look at this article from the
Lanclet medical journal article, "How will country-based mitigation
measures influence the course of the COVID-19 epidemic?":

https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(20)30567-5/fulltext

The takeaway is it's really not clear how long it will take for the
COVID-19 pandemic to run its course --- but some of their sample
curves extend out for of 5-6 months or longer.  So while we are
continuing to plan that LPC will take place, it's only responsible to
consider what we should do if in fact health and safety restrictions
are such that we might not be able to hold *any* Linux systems
conferences in 2020.

In that case, we might be forced to either keep TAB members in place
beyond their original elected term, or we might have to go to a pure
electronic voting for the upcoming TAB election.  I very much hope
that won't be the case, but we need to be prepared for that
eventuality.

(I'll keep silent about what I think of the current US
Administration's competence in steering us through this crisis, except
to note that in South Korea, they are testing 10,000 people a day,
using drive-through centers, and we haven't been able to test that
many *total* so far in the US, and there are Biogen employees in
Boston and Life Care Center employees in Kirkland, Washington, who are
still waiting for COVID-19 test availability....)

						- Ted

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Jani Nikula]

On Thu, 12 Mar 2020, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> So that means we need to be smart about how we pick the criteria.
> Using a kernel.org account might be a good approach, since it would be
> a lot harder for a huge number of sock puppet accounts to meet that
> criteria.

Per [1] and [2], kernel.org accounts "are usually reserved for subsystem
maintainers or high-profile developers", but apparently it's at the
kernel.org admins discretion to decide whether one is ultimately
eligible or not. Do we want the kernel.org admin to have the final say
on who gets to vote? Do we want to encourage people to have kernel.org
accounts for no other reason than to vote?

Furthermore, having a kernel.org account imposes the additional
requirement that you're part of the kernel developers web of trust,
i.e. that you've met other kernel developers in person. Which is a kind
of awkward requirement for enabling electronic voting to be inclusive to
people who can't attend in person.

Seems like having a kernel.org account is just a proxy for the criteria,
and one that also lacks transparency, and has problems of its own.

Not that I'm saying there's an easy solution, but obviously kernel.org
account is not as problem free as you might think.

BR,
Jani.


[1] https://www.kernel.org/faq.html
[2] https://korg.wiki.kernel.org/userdoc/accounts

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Greg KH]

On Fri, Mar 13, 2020 at 10:58:00AM +0200, Jani Nikula wrote:
> On Thu, 12 Mar 2020, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> > So that means we need to be smart about how we pick the criteria.
> > Using a kernel.org account might be a good approach, since it would be
> > a lot harder for a huge number of sock puppet accounts to meet that
> > criteria.
> 
> Per [1] and [2], kernel.org accounts "are usually reserved for subsystem
> maintainers or high-profile developers", but apparently it's at the
> kernel.org admins discretion to decide whether one is ultimately
> eligible or not. Do we want the kernel.org admin to have the final say
> on who gets to vote? Do we want to encourage people to have kernel.org
> accounts for no other reason than to vote?

We are using the "kernel.org account" as a way to verify that you really
are part of our developer/maintainer community and that you are part of
the "web of trust" and an actual person.

That is the goal here, if you know of some other way to determine this,
please let us know.  We went through many iterations of this and at the
moment, it is the best we can come up with.

Also, note that the "kernel.org admin" is really a team of people who
have been doing this for 9 years, it's not a single person responsible
for giving out new accounts to people that do not meet the obvious
requirement levels as published on kernel.org

> Furthermore, having a kernel.org account imposes the additional
> requirement that you're part of the kernel developers web of trust,

That is exactly what we want.

> i.e. that you've met other kernel developers in person. Which is a kind
> of awkward requirement for enabling electronic voting to be inclusive to
> people who can't attend in person.

Yes, we know that, but it does mean that you are "known" to someone
else, which is the key here.

> Seems like having a kernel.org account is just a proxy for the criteria,
> and one that also lacks transparency, and has problems of its own.

What is not transparent about how to get a kernel.org account?

> Not that I'm saying there's an easy solution, but obviously kernel.org
> account is not as problem free as you might think.

We are not saying it is "problem free", but what really is the problem
with it?

thanks,

greg k-h

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Vlastimil Babka]

On 3/13/20 10:35 AM, Greg KH wrote:
>> Not that I'm saying there's an easy solution, but obviously kernel.org
>> account is not as problem free as you might think.
> 
> We are not saying it is "problem free", but what really is the problem
> with it?

IIUC there is no problem for its current use, but it would be rather restrictive
if it was used as the only criterion for being able to vote for TAB remotely.

> thanks,
> 
> greg k-h
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Greg KH]

On Fri, Mar 13, 2020 at 10:41:57AM +0100, Vlastimil Babka wrote:
> On 3/13/20 10:35 AM, Greg KH wrote:
> >> Not that I'm saying there's an easy solution, but obviously kernel.org
> >> account is not as problem free as you might think.
> > 
> > We are not saying it is "problem free", but what really is the problem
> > with it?
> 
> IIUC there is no problem for its current use, but it would be rather restrictive
> if it was used as the only criterion for being able to vote for TAB remotely.

Given that before now, there has not be any way to vote for the TAB
remotely, it's less restrictive :)

These are "baby steps" we are taking here, to try to allow for remote
voting.  We are not saying this is the end-all-be-all solution, but you
have to give Laura credit for coming up with this as "better than
nothing" which is what has been the case for the past decade or so.

thanks,

greg k-h

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Geert Uytterhoeven]

Hi Greg,

On Fri, Mar 13, 2020 at 11:08 AM Greg KH <greg@kroah.com> wrote:
> On Fri, Mar 13, 2020 at 10:41:57AM +0100, Vlastimil Babka wrote:
> > On 3/13/20 10:35 AM, Greg KH wrote:
> > >> Not that I'm saying there's an easy solution, but obviously kernel.org
> > >> account is not as problem free as you might think.
> > >
> > > We are not saying it is "problem free", but what really is the problem
> > > with it?
> >
> > IIUC there is no problem for its current use, but it would be rather restrictive
> > if it was used as the only criterion for being able to vote for TAB remotely.
>
> Given that before now, there has not be any way to vote for the TAB
> remotely, it's less restrictive :)

But people without kernel.org accounts could still vote in person before,
right?

Obviously the next step beyond "has a kernel.org account" is "is listed
in MAINTAINERS".  All of these can be assumed to be real humans, too.
However, that's still more restrictive than before, as it rules out people
who are not maintainers.

So next step would be developers/maintainers with an SoB.  I think it's still
safe to assume they are real humans, too.
Add a minimum number of commits[*] to raise the bar a little bit, and avoid
the whitespace-fixers who just want to vote.

[*] And e.g. count commits more than one year ago half, more than N years
    ago 1/2^N.  Perhaps add another penalty for staging cleanups ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Greg KH]

On Fri, Mar 13, 2020 at 11:16:36AM +0100, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Fri, Mar 13, 2020 at 11:08 AM Greg KH <greg@kroah.com> wrote:
> > On Fri, Mar 13, 2020 at 10:41:57AM +0100, Vlastimil Babka wrote:
> > > On 3/13/20 10:35 AM, Greg KH wrote:
> > > >> Not that I'm saying there's an easy solution, but obviously kernel.org
> > > >> account is not as problem free as you might think.
> > > >
> > > > We are not saying it is "problem free", but what really is the problem
> > > > with it?
> > >
> > > IIUC there is no problem for its current use, but it would be rather restrictive
> > > if it was used as the only criterion for being able to vote for TAB remotely.
> >
> > Given that before now, there has not be any way to vote for the TAB
> > remotely, it's less restrictive :)
> 
> But people without kernel.org accounts could still vote in person before,
> right?

Yes, and they still can today, this is expanding the pool, not
restricting it.

thanks,

greg k-h

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Geert Uytterhoeven]

Hi Greg,

On Fri, Mar 13, 2020 at 11:37 AM Greg KH <greg@kroah.com> wrote:
> On Fri, Mar 13, 2020 at 11:16:36AM +0100, Geert Uytterhoeven wrote:
> > On Fri, Mar 13, 2020 at 11:08 AM Greg KH <greg@kroah.com> wrote:
> > > On Fri, Mar 13, 2020 at 10:41:57AM +0100, Vlastimil Babka wrote:
> > > > On 3/13/20 10:35 AM, Greg KH wrote:
> > > > >> Not that I'm saying there's an easy solution, but obviously kernel.org
> > > > >> account is not as problem free as you might think.
> > > > >
> > > > > We are not saying it is "problem free", but what really is the problem
> > > > > with it?
> > > >
> > > > IIUC there is no problem for its current use, but it would be rather restrictive
> > > > if it was used as the only criterion for being able to vote for TAB remotely.
> > >
> > > Given that before now, there has not be any way to vote for the TAB
> > > remotely, it's less restrictive :)
> >
> > But people without kernel.org accounts could still vote in person before,
> > right?
>
> Yes, and they still can today, this is expanding the pool, not
> restricting it.

Oh right, assumed we'll still have a conference in person, and unrestricted
travel.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Steven Rostedt]

On Fri, 13 Mar 2020 11:50:45 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > > > Given that before now, there has not be any way to vote for the TAB
> > > > remotely, it's less restrictive :)  
> > >
> > > But people without kernel.org accounts could still vote in person before,
> > > right?  
> >
> > Yes, and they still can today, this is expanding the pool, not
> > restricting it.  
> 
> Oh right, assumed we'll still have a conference in person, and unrestricted
> travel.

Correct. But if we don't change the voting requirements, and the conference
is canceled, or people are restricted from traveling, then those people
will not be able to vote with the current charter.

We are trying to extend who can vote beyond those that the charter allows.
We are not preventing those that can vote under the current rules from
voting.  IIUC, we are trying to create absentee voting which we never had
before. Thus, you can either vote the current way by getting travel to
wherever Kernel Summit is and attending the conference, or we can extend
the charter so that if you can not come for whatever reason, you have an
option to vote remotely, if you satisfy the new requirements. Remember, not
attending means you do not satisfy the current requirements.

The TAB has bikeshed this a bit internally, and came up with the conclusion
that kernel.org accounts is a very good "first step". If this proves to be
a problem, we can look at something else. This is why we are being a bit
vague in the changes so that if something better comes along we can switch
to that. After some experience in various methods (if we try various
methods), we could always make whatever method works best as an official
method at a later time.

But for now, we need to come up with something that makes it hard for
ballot stuffing, and a kernel.org account (plus activity in the kernel)
appears to be the best solution we know of.

-- Steve

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Jani Nikula]

On Fri, 13 Mar 2020, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 13 Mar 2020 11:50:45 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
>> > > > Given that before now, there has not be any way to vote for the TAB
>> > > > remotely, it's less restrictive :)  
>> > >
>> > > But people without kernel.org accounts could still vote in person before,
>> > > right?  
>> >
>> > Yes, and they still can today, this is expanding the pool, not
>> > restricting it.  
>> 
>> Oh right, assumed we'll still have a conference in person, and unrestricted
>> travel.
>
> Correct. But if we don't change the voting requirements, and the conference
> is canceled, or people are restricted from traveling, then those people
> will not be able to vote with the current charter.
>
> We are trying to extend who can vote beyond those that the charter allows.
> We are not preventing those that can vote under the current rules from
> voting.  IIUC, we are trying to create absentee voting which we never had
> before. Thus, you can either vote the current way by getting travel to
> wherever Kernel Summit is and attending the conference, or we can extend
> the charter so that if you can not come for whatever reason, you have an
> option to vote remotely, if you satisfy the new requirements. Remember, not
> attending means you do not satisfy the current requirements.
>
> The TAB has bikeshed this a bit internally, and came up with the conclusion
> that kernel.org accounts is a very good "first step". If this proves to be
> a problem, we can look at something else. This is why we are being a bit
> vague in the changes so that if something better comes along we can switch
> to that. After some experience in various methods (if we try various
> methods), we could always make whatever method works best as an official
> method at a later time.
>
> But for now, we need to come up with something that makes it hard for
> ballot stuffing, and a kernel.org account (plus activity in the kernel)
> appears to be the best solution we know of.

Thanks for writing this. I, for one, would welcome more open and
proactive communication from the TAB.

Have you considered whether the eligibility for running and voting
should be made the same? As it is, absolutely anyone can self-nominate
and run.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Theodore Y. Ts'o]

On Fri, Mar 13, 2020 at 04:10:29PM +0200, Jani Nikula wrote:
> 
> Have you considered whether the eligibility for running and voting
> should be made the same? As it is, absolutely anyone can self-nominate
> and run.

That's always been the case.  However, at least historically, people
who weren't physically present has never been successful.

One of the changes last year with the adoption of electronic voting
was there was only a written nomination statement and not a short
spoken statement before the vote.

					- Ted

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Jani Nikula]

On Fri, 13 Mar 2020, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> On Fri, Mar 13, 2020 at 04:10:29PM +0200, Jani Nikula wrote:
>> 
>> Have you considered whether the eligibility for running and voting
>> should be made the same? As it is, absolutely anyone can self-nominate
>> and run.
>
> That's always been the case.  However, at least historically, people
> who weren't physically present has never been successful.

Oh? May I ask for that to be clarified in the TAB charter, please.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[James Bottomley]

On Fri, 2020-03-13 at 17:08 +0200, Jani Nikula wrote:
> On Fri, 13 Mar 2020, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> > On Fri, Mar 13, 2020 at 04:10:29PM +0200, Jani Nikula wrote:
> > > 
> > > Have you considered whether the eligibility for running and
> > > voting should be made the same? As it is, absolutely anyone can
> > > self-nominate and run.
> > 
> > That's always been the case.  However, at least historically,
> > people who weren't physically present has never been successful.
> 
> Oh? May I ask for that to be clarified in the TAB charter, please.

It's a historical observation, not a rule.  In fact, it does have an
exception: GregKH was elected in Edinburgh in 2012 without being
physically present at the voting (although he was in Edinburgh at the
time).

James

RE: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Bird, Tim]

> -----Original Message-----
> From:  James Bottomley
> 
> On Fri, 2020-03-13 at 17:08 +0200, Jani Nikula wrote:
> > On Fri, 13 Mar 2020, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> > > On Fri, Mar 13, 2020 at 04:10:29PM +0200, Jani Nikula wrote:
> > > >
> > > > Have you considered whether the eligibility for running and
> > > > voting should be made the same? As it is, absolutely anyone can
> > > > self-nominate and run.
> > >
> > > That's always been the case.  However, at least historically,
> > > people who weren't physically present has never been successful.
> >
> > Oh? May I ask for that to be clarified in the TAB charter, please.
> 
> It's a historical observation, not a rule.  In fact, it does have an
> exception: GregKH was elected in Edinburgh in 2012 without being
> physically present at the voting (although he was in Edinburgh at the
> time).

I was elected in Prague in 2017.  I was onsite, but had a conflict so
was not present for the vote.  So it's happened, but it has been rare
for someone to be elected while not present at the vote.  I'll be honest.
The fact that ELC was co-located with the kernel summit that year 
probably had a lot to do with my win.  IMHO it would be nice
to reduce the effect of the event pairing on the elections, so I really
welcome the movement to absentee voting (even though it helped
me once :-) ).

With regard to clarifying it for transparency, I think that would be good.
We have customarily sent out a request for nominations by e-mail
prior to the kernel summit.  I don't recall the wording, but I think 
the nomination instructions included the information that you didn't
need to be present to run.  If I'm mis-remembering this and it's not
there, it would be good to add it.
 -- Tim

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Steven Rostedt]

On Fri, 13 Mar 2020 17:14:51 +0000
"Bird, Tim" <Tim.Bird@sony.com> wrote:

> I was elected in Prague in 2017.  I was onsite, but had a conflict so
> was not present for the vote.  So it's happened, but it has been rare
> for someone to be elected while not present at the vote.  I'll be honest.
> The fact that ELC was co-located with the kernel summit that year 
> probably had a lot to do with my win.  IMHO it would be nice
> to reduce the effect of the event pairing on the elections, so I really
> welcome the movement to absentee voting (even though it helped
> me once :-) ).

Last year I too was on site, but missed the election meeting as I was too
busy running Plumbers ;-) (Like you were running ELC) And I too was elected.
But last year was the first time we had electronic voting and you could vote
without being at the election. You only had to be present at the conference.

Last year we also removed the speech and instead only had the published
statements.

-- Steve

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[James Bottomley]

On Fri, 2020-03-13 at 16:10 +0200, Jani Nikula wrote:
> On Fri, 13 Mar 2020, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Fri, 13 Mar 2020 11:50:45 +0100
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > 
> > > > > > Given that before now, there has not be any way to vote for
> > > > > > the TAB remotely, it's less restrictive :)  
> > > > > 
> > > > > But people without kernel.org accounts could still vote in
> > > > > person before, right?  
> > > > 
> > > > Yes, and they still can today, this is expanding the pool, not
> > > > restricting it.  
> > > 
> > > Oh right, assumed we'll still have a conference in person, and
> > > unrestricted travel.
> > 
> > Correct. But if we don't change the voting requirements, and the
> > conference is canceled, or people are restricted from traveling,
> > then those people will not be able to vote with the current
> > charter.
> > 
> > We are trying to extend who can vote beyond those that the charter
> > allows.  We are not preventing those that can vote under the
> > current rules from voting.  IIUC, we are trying to create absentee
> > voting which we never had before. Thus, you can either vote the
> > current way by getting travel to wherever Kernel Summit is and
> > attending the conference, or we can extend the charter so that if
> > you can not come for whatever reason, you have an option to vote
> > remotely, if you satisfy the new requirements. Remember, not
> > attending means you do not satisfy the current requirements.
> > 
> > The TAB has bikeshed this a bit internally, and came up with the
> > conclusion that kernel.org accounts is a very good "first step". If
> > this proves to be a problem, we can look at something else. This is
> > why we are being a bit vague in the changes so that if something
> > better comes along we can switch to that. After some experience in
> > various methods (if we try various methods), we could always make
> > whatever method works best as an official method at a later time.
> > 
> > But for now, we need to come up with something that makes it hard
> > for ballot stuffing, and a kernel.org account (plus activity in the
> > kernel) appears to be the best solution we know of.
> 
> Thanks for writing this. I, for one, would welcome more open and
> proactive communication from the TAB.
> 
> Have you considered whether the eligibility for running and voting
> should be made the same? As it is, absolutely anyone can self-
> nominate and run.

When the TAB charter was written (in 2006), the original reason was to
prevent manipulation (real or imagined) by the committee who would then
become the arbiters of nominations and thus able to influence who might
run for the TAB.  There are a couple of reasons for the electorate
clause: when the TAB was formed, it was done by the kernel developers
unhappy at the way OSDL (precursor organization to the LF) was behaving
with regard to the kernel, who forced their way onto its board and
formed the TAB to gain input and control on behalf of kernel
developers, so the TAB was formed by kernel developer for kernel
developers and, since most other non-kernel open source groups had
their own foundation like entities, keeping it kernel only wasn't seen
as a problem.  The other reason was that OSDL was a bit unhappy to be
reformed in this way and we foresaw that one way to dilute the
reforming influence of the TAB would be to dilute kernel developer
representation since they were the main community interested in that
reform.  When the OSDL became the LF, some of the initial antagonism
and need for reform went away and the elections were opened to the co-
located conferences as a sign of improved trust.

James

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Jani Nikula]

On Fri, 13 Mar 2020, Greg KH <greg@kroah.com> wrote:
> On Fri, Mar 13, 2020 at 10:58:00AM +0200, Jani Nikula wrote:
>> On Thu, 12 Mar 2020, "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
>> > So that means we need to be smart about how we pick the criteria.
>> > Using a kernel.org account might be a good approach, since it would be
>> > a lot harder for a huge number of sock puppet accounts to meet that
>> > criteria.
>> 
>> Per [1] and [2], kernel.org accounts "are usually reserved for subsystem
>> maintainers or high-profile developers", but apparently it's at the
>> kernel.org admins discretion to decide whether one is ultimately
>> eligible or not. Do we want the kernel.org admin to have the final say
>> on who gets to vote? Do we want to encourage people to have kernel.org
>> accounts for no other reason than to vote?
>
> We are using the "kernel.org account" as a way to verify that you really
> are part of our developer/maintainer community and that you are part of
> the "web of trust" and an actual person.
>
> That is the goal here, if you know of some other way to determine this,
> please let us know.  We went through many iterations of this and at the
> moment, it is the best we can come up with.

Ted's mail seemed like it was thrown around as an idea, not something
you're settling on.

> Also, note that the "kernel.org admin" is really a team of people who
> have been doing this for 9 years, it's not a single person responsible
> for giving out new accounts to people that do not meet the obvious
> requirement levels as published on kernel.org
>
>> Furthermore, having a kernel.org account imposes the additional
>> requirement that you're part of the kernel developers web of trust,
>
> That is exactly what we want.

Fair enough.

>> i.e. that you've met other kernel developers in person. Which is a kind
>> of awkward requirement for enabling electronic voting to be inclusive to
>> people who can't attend in person.
>
> Yes, we know that, but it does mean that you are "known" to someone
> else, which is the key here.
>
>> Seems like having a kernel.org account is just a proxy for the criteria,
>> and one that also lacks transparency, and has problems of its own.
>
> What is not transparent about how to get a kernel.org account?

There is no way of knowing whether you're eligible to vote until you
apply for a kernel.org account and either get approved or rejected.

The current "obvious" requirement levels are not obvious to me. How many
contributions is enough? Is everyone in MAINTAINERS eligible, or do you
have to be a high-profile maintainer/developer? What is a high-profile
developer? How many people in the web of trust must you have met in
person?

And it actually seems like you think it's a good thing the admin team
can make a subjective decision on the above.

It may seem completely transparent and fair and objective on the
*inside*, but it does not look that way on the *outside*. Which is kind
of the definition of transparent. Or lack of.

>> Not that I'm saying there's an easy solution, but obviously kernel.org
>> account is not as problem free as you might think.
>
> We are not saying it is "problem free", but what really is the problem
> with it?

Seems that some of what I thought was a bug is a feature for you, so I
suppose it's better to focus on the transparency.

On that note, and since this relates to the charter, how's the "The TAB
shall provide transparent and timely reporting (through any mechanism it
deems appropriate) to the Community at large on all of its activities"
coming along...?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Sasha Levin]

On Fri, Mar 13, 2020 at 12:30:20PM +0200, Jani Nikula wrote:
>On Fri, 13 Mar 2020, Greg KH <greg@kroah.com> wrote:
>There is no way of knowing whether you're eligible to vote until you
>apply for a kernel.org account and either get approved or rejected.
>
>The current "obvious" requirement levels are not obvious to me. How many
>contributions is enough? Is everyone in MAINTAINERS eligible, or do you
>have to be a high-profile maintainer/developer? What is a high-profile
>developer? How many people in the web of trust must you have met in
>person?

Personally, I think that our definition of who can vote should be "any
member of our community", but it's not practical, right?

This process will take years, and each year I would expect us to
increase the voting pool by a significant amount. Maybe we should focus
too much on what restrictions are in affect in the current year, but
rather on trying to learn how well these restrictions worked and which
of them we can lift.

-- 
Thanks,
Sasha

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Steven Rostedt]

On Fri, 13 Mar 2020 09:05:36 -0400
Sasha Levin <sashal@kernel.org> wrote:

> Personally, I think that our definition of who can vote should be "any
> member of our community", but it's not practical, right?

The question is, how do you define "any member of the community". Should
drive by patch senders have the same influence as the a maintainer that is
spending hours working on the project?

It really comes down to what is the TAB? It is the Linux Foundation's
Technical Advisory Board. As the name suggests, its the way to have
influence to the Linux Foundation on behalf of the Linux kernel community.

I really believe that those with the largest stakes in the success of the
Linux kernel have the most influence. Otherwise we could easily end up with
mob mentality and get the same kind of representation that the United
States currently has.

-- Steve

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

On Fri, Mar 13, 2020 at 12:30:20PM +0200, Jani Nikula wrote:
> There is no way of knowing whether you're eligible to vote until you
> apply for a kernel.org account and either get approved or rejected.
> 
> The current "obvious" requirement levels are not obvious to me. How many
> contributions is enough? Is everyone in MAINTAINERS eligible, or do you
> have to be a high-profile maintainer/developer? What is a high-profile
> developer? How many people in the web of trust must you have met in
> person?

Anyone listed in MAINTAINERS is eligible to get an auto-approved account 
on kernel.org, but they *must* satisfy the web of trust requirement:

- their key is signed by 2 other people who already have a kernel.org 
  account (marginal trust), OR
- their key is signed by one of the following people (full trust):

  - H. Peter Anvin
  - Greg Kroah-Hartman
  - Ted Ts'o
  - Linus Torvalds
  - Dirk Hohndel
  - James Bottomley

Anyone who is not in MAINTAINERS but feel they should have an account on 
kernel.org can still apply if they provide a reason behind their 
request. Such cases are fairly rare and usually include collaboration on 
non-kernel projects that are also hosted on kernel.org (there aren't 
that many, but there are a few). The web of trust requirement is exactly 
the same, but the final approval is not automatic. I forward these 
requests to the above 6 people and it is sufficient for at least one 
person to say "aye" for the account to be approved.

It is also important to highlight a distinction between "having an 
account" and having a kernel.org email forwarding address. For this 
particular case I was requested to provide a list of people with *active 
accounts* on kernel.org, meaning that they have performed a git+ssh 
operation within the past 12 months.

> And it actually seems like you think it's a good thing the admin team
> can make a subjective decision on the above.

The LF IT admin team does not make any decisions -- all decisions are 
taken by the above 6 people (unless the person is in MAINTAINERS, in 
which case their approval is implicit).

> It may seem completely transparent and fair and objective on the
> *inside*, but it does not look that way on the *outside*. Which is kind
> of the definition of transparent. Or lack of.

I hope I helped clarify the procedure. Of course, as the person actually 
creating accounts I'm the final arbiter of all decisions. If I had any 
malicious intents, I could totally subvert the whole process -- so in 
the end you just have to trust me to be on the side of "lawful good."

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Ksummit-discuss] [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter

[Jani Nikula]

On Fri, 13 Mar 2020, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> I hope I helped clarify the procedure.

Yes, thank you. May I ask for the clarifications to be made to [1] and
[2], as well as have them agree on the requirements, please?

BR,
Jani.


[1] https://www.kernel.org/faq.html
[2] https://korg.wiki.kernel.org/userdoc/accounts

-- 
Jani Nikula, Intel Open Source Graphics Center