[gentoo-nfp] Questions re mgorny trustee manifesto

[Robin H. Johnson]

Dear Michał,

I have read your your manifesto for election as Trustee, and have some
questions about issue you raise there. They also impact what you think
of the Council's work, and I believe a public thread can help clarify
both your positions, as well as others who might be running for
positions in council or trustees.


> 1. Gentoo should be self-governing, and the Foundation should support
>    it.  Think of it as a good parent that cares about the well-being
>    of its child but lets it make its own decisions and make its own
>    mistakes.
If the mistakes have legal consequences: 
1.i. To what extent have you examined which of the involved parties have
     individual & joint liabilities for those mistakes?
1.ii. Aside from the legalities of HOW to share the joint & individual
      liabilities, how do you THINK the liabilities should be shared?

> 1.a. ...
>      Example: Council decides that <init1> is not worth supporting
>      anymore, and developers should focus on <init2> anymore.
> 1.c. ...
>      Example: Council decides that <init1> is not worth supporting.
>      However, a developer requests a bounty for improving status
> 	   of <init1>.
(And also 1.c. which has the same premise)

I agree with your "GOOD" responses here: they are clear that there should
be dialogue & compromise, while your "BAD" responses are basically
unilateral actions by the Trustees. 

What worries me is the level of power that you ascribe to the council
over developers & projects.

Can you clarify your implication here that the Council can demand
developers remove or otherwise stop supporting a package by Council
decree? 

Short of legal reasons to do so, I believe that this would set a
dangerous precedent directly. 

Gentoo has a historical practice of permitting developers to support
whatever they want to work on, provided it doesn't directly conflict
with other packages: Users should have the CHOICE of both init1 & init2
as long as developers are willing to maintain them.

The bounty would need specific careful wording regardless, and would
have to be free of conflict of interest. E.g. ensure that init1 remains
a choice in Gentoo.

The same should apply to architectures, not just packages.
Should the council be able to unilateral decide, despite a developer's
intentions, that an architecture is no longer supported at all?
Can the developer submit funding requests for new hosts in that
architecture that live in the racks at OSL?

> 2. Transparency is important.  Trustees should clearly inform
>    the community what is happening, what are they doing, what
>    the outcome of meetings is, in proper human-intended messages.
>    The notable exception of what can't be revealed due to law
>    or contracts.
To be clear, you're happy as long as the outcome is transparent?
Contract discussions are usually considered sensitive to business needs, and
generally not public, even if most of the contract outcome is public in the
end.

What do you think that the Trustees can do to better convey ongoing trustee
activity, that occurs between meetings, and/or in the absence of meetings?

Years ago, I ran for a trustee position on a manifesto of increasing
transparency. Retrospectively, I feel that I only made a little progress into
the overall scope of the issue.

> 3. Trustees were split around the world so far, and in the last term
>    they practically failed to meet.  Ideally, Trustees should try
>    to arrange regular open meetings with the community.  However,
>    if that becomes cumbersome they should focus on asynchronous
>    communications (mail) and/or smaller meetings, with votes being
>    done via mail or bugs.  Inability to arrange regular meetings
>    must not paralyze the Foundation.
As Antarus pointed out elsewhere, only the AGM is formally required by law, and
it must be open.

I think that the asynchronous structure, and smaller non-formal private setting
used in the latest term helped a lot towards actual progress on events. The
down-side as you raised in point 2, is that there was very little transparency
to it.

As the first concrete example, the matter of retaining Corporate Capital CPA
was discussed heavily on the internal trustees@ alias, as well as the
trustees-only IRC channel. The discussions included our own prep for the two
phone calls with the CPA (preparing various documentation they asked for on
bylaws, articles of incorporation, financial statements, prior IRS
interactions), back-channel during the phone calls, notes during the phone
calls, and the actual recording of the calls.

The two resulting motions [exploration with IRS, and filing preperations] were
on bugzilla & email.

The Nitrokey business discussions and implementation discussions were ALSO
similarly opaque, leading the this impression of 'failed to meet' meaning
'paralyzed'.

> 4. & 5. (discussion of the future legal structure of the NFP)
I think we should cross that bridge when we get to it, and continue efforts on
the things needed to GET to either of these outcomes. Make sure the present
efforts are lost or stalled as much as possible.

To that end, I need to write a message to the -project list looking for any
existing developers with both book-keeping skills & some time on their hands to
help wrangle the raw FY2019 data.

> 6. We should aim to minimize the split between non-Foundation
>    and Foundation part of Gentoo.  This is already partially solved
>    by requiring Trustees to be Gentoo developers.  The next logical step
>    is to require all Foundation members to be developers as well.
>    This involves working with Council/Recruiters to extend developer
>    status for Foundation members interested in it.
I say here that I'm going to agree to disagree with you on the concept, while
willing to discuss the nuances of implementation.

I think that membership SHOULD be wider than the developer base, provided that
all members are individuals (no corporations should be members). This primarily
has impacts in fund-raising: Look at the membership & corporate sponsors of the
ASF. The many but not all of ASF corporate sponsors have or had at least one
individual who is or was a member of the ASF. The members MAY contribute in
non-coding ways, but might be as simple as voting on issues that are the
concern of their employer [I have heard hearsay about bloc-voting behaviors
within the ASF, but I have nothing to corroborate them].

Membership should conveys a vested interest in the actions of the Foundation,
and the outcomes in Gentoo Linux.

If your intent is to create an "easy" route to Foundation members to gain
developer status, and changing undertakers practices in the process, then
please count me as interested in your proposal.

As a first step, how about move undertakers to taking away unused commit bits,
but not dropping people from being developers. Don't worry about "@gentoo.org"
being a status signifier.

-- 
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