Re: [gentoo-nfp] Questions re mgorny trustee manifesto

[Michał Górny]

On Thu, 2019-07-04 at 01:58 +0000, Robin H. Johnson wrote:
> 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?

I haven't.

> 1.ii. Aside from the legalities of HOW to share the joint & individual
>       liabilities, how do you THINK the liabilities should be shared?

You'd have to be more specific of what 'mistakes with legal
consequences' you mean.  I don't think you can blanket assume
the responsibility will always be the same independently on what ground
the legal consequences are taken.

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

The whole purpose of having a Council is for the Council to have power
over developers.  If it can't enforce its decisions, there is no purpose
in its existence.  Sure, it should do only wise decisions, and if it
doesn't we have GR to override it.

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

No, that's not my implication.  I merely provided an exaggerated example
where the vast majority of developers already stopped supporting
the package but a small minority tries to force them to work on it.

So, no, I don't see Council preventing people from working on a package.
However, I can see QA forcing it to be masked or removed if it is causes
harm to users and maintainers do nothing about that, and I see Council
supporting that QA motion.

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

How is that fair against developers supporting other options, who put
a lot of effort supporting them for free?  Sure, we already are
in the position where big companies hire Gentoo developers and therefore
control which options are better supported with their money.  But we
shouldn't break the balance even more with internal donations.

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

A single developer's intentions or multiple developer's intentions?
The Council has already marked a bunch of architectures exp, following
the majority requests, simply because developers intent on supporting
those architectures weren't able to do the necessary work.

And sure, you are looking into funding a new SPARC box right now. 
Should the Council be able to block that?  If it has good reasons, then
yes.  However, in this case I don't think there are good reasons to
block it.  Would someone request us to spend half of Foundation
resources on m68k hardware where Council can clearly estimate that our
m68k wouldn't be able to really use, then yes, it should be able to
reject that request.

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

Yes.  I'm talking about releasing the public information,
and summarizing whatever can't be public if that's allowed.

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

RFCs, summaries, news posts.  There's a lot of ways you can convey
information and notices, so we ought to use them rather than expect
people to have to track IRC, mailing lists, Bugzilla and sieve through
all the noise.

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

I suppose opaque makes sense if non-public data has been processed. 
However, I think it would be reasonable to have some kind of public
summaries or reports for that kind of activities.  Especially,
if a motion is about to be set, I believe it is due to publish a summary
beforehand and give the community a chance to give feedback.

I'm not saying you need to wait for it if the matter is urgent. 
However, if things like that happened, we'd have a lot less
misunderstandings.

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

Did you mean 'not lost'?

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

In the Gentoo development model, Foundation member voting rights have
little real impact on Gentoo development.  I'm personally against giving
people member status just to lie to them that it's really meaningful. 
If someone wants to have vote on how Gentoo runs, he either needs to
become a developer or have arguments that are convincing to developers.

That said, don't the Bylaws say that membership can't be bought? 
Because the above sounds like the exact opposite of that.

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

Short-term, sure, we can look if the existing members have what it takes
to become non-commit-access developers.  Long-term, my goal is not to
have separate route to become Foundation members.

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

We already doing that whenever there is real interest; antarus can
confirm that.

-- 
Best regards,
Michał Górny