Re: [gentoo-nfp] [RFC] Alternative methods for determining 'interest in Foundation affairs'

[Robin H. Johnson]

On Thu, Sep 05, 2019 at 01:45:25PM -0700, Alec Warner wrote:
> > 1. It intrudes on privacy of voters.  I suppose it's not *that major*
> > but still I don't think it's appropriate to publish a 'shame list' of
> > people who haven't voted for whatever reason.
> I believe in your right to vote and have the content of the vote be
> private. I don't believe in your right to vote anonymously in Foundation
> elections. The fact that you voted should be public. The foundation has
> minimal requirements for membership; if you don't vote in foundation
> affairs (1 vote a year!) then I don't see the point in being a member. It's
> basically the only difference afforded to members[0]! I don't believe we do
> publish a list of who voted in every election, but we do publish a
> membership list and there is definitely a correlation and its intentional.
Point of order:
The lists of which voters cast a ballot is public in the elections repo,
and has been available for a long time. This applies not just for
Trustee elections, but for all other elections in the votify system.

If you consider various real world voting systems, they generally
require some form of electoral roll, on which voters are checked off, to
prevent voting multiple times (this can be enforced with other
mechanisms). As a tidbit in research, apparently Italy used to have
mandatory voting, and publicly posted lists of those who did not vote as
a form of sanction.

> > 2. It introduces a big weakness in the system.  My whole idea was to
> > make it practically impossible to sniff votes after the election is
> > prepared.  With this solution, anyone with sufficient privileges
> > (election officials, infra) can trivially passively sniff votes.
> We need to know who cast votes, we don't need to know the content of the
> votes. I assume building such a system is possible (maybe it isn't?)
mgorny's system design is explicitly around building protections to
enable LESS trust being placed in infra & voting officials.

Timing correlation in when a vote or stub appears in the system is a
concern in that environment.

I agree that it should be possible to build this requirement into the
system, but at what cost in development.

> > 3. It is really meaningless.  Casting a vote does not really indicate
> > any interest in GF.  It only indicates that someone has done the minimal
> > effort to avoid being kicked.  There is no reason to conflate the two.
> I'm certainly interested in other avenues of interest, but I don't see very
> many in this thread other than "AGM attendance" and "asking people if they
> are interested[0]"
- Does involvement on mailing lists count? 
- What other ways outside development might somebody be involved in
  Gentoo? Not everybody is a developer, let alone an ebuild developer.
  What if we wound up with PR people who weren't devs at all, but loved
  to talk about Gentoo?

> > I believe we should consider other options of determining activity.
> > Depending on whether we actually want to keep people actually interested
> > in GF, or just those caring enough to stay, I can think of a few
> > options.
I'd say those options should be in addition to, rather than instead of
voting.

> > The most obvious solution would be to take AGM attendance as indication
> > of interest.  It would also create an interest in actually attending,
> > and make it possible to finally reach a quorum.  However, it's rather
> > a poor idea given that AGMs tend to happen in middle of the night for
> > European devs.  We would probably have to accept excuses for not
> > attending, and then measuring attendance will probably be meaningless
> > anyway.
> Attendance of a single meeting per year is a bad idea without some kind of
> proxy system in place, same as any corporation.
It also doesn't capture the intent of more ongoing/"regular" interest in
Gentoo, just a once-per-year snapshot.

> > Another option (which some people aren't going to like) is to require
> > all Foundation members to be Gentoo devs (but not the other way around),
> > and then terminate GF membership along with developer status.  Given
> > that there's only a few non-dev members, and most of them are retired
> > devs whose membership simply didn't terminate by existing rules yet, I
> > think there shouldn't really be a problem in making the few interested
> > members non-commit devs by existing rules.
> This doesn't really imply interested in the Foundation either though;
> because the developership and Foundation are separate.
If this includes making non-commit developership easier to
get AND maintain (the undertaker discussions about how to gauge
ongoing involvement of non-commit devs is very relevant to this), then I
have no conceptual problem with requiring all Foundation members to be
developers (It should still be possible to be a developer WITHOUT being
a Foundation member).

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@g.o
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136