[gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Michał Górny]

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

Hi, everyone.

The text of a new GLEP proposal follows.  The GLEP implements a General
Resolution mechanism based on the one in Debian; the idea was initially
proposed by Matthias Maier [1]; however, he didn't manage to find time
to write the GLEP.

Please review the proposed text and let me know what you think.  Please
note that the numbers presented have been chosen arbitrarily and are up
for discussion.

[1]:https://archives.gentoo.org/gentoo-project/message/973be0a662b3cc74aa118a1128dcac9e


---
GLEP: 9999
Title: Gentoo General Resolution
Author: Michał Górny <mgorny@gentoo.org>
Type: Standards Track
Status: Draft
Version: 1
Created: 2018-06-22
Last-Modified: 2018-06-28
Post-History: 
Content-Type: text/x-rst
Requires: 
Replaces: 
---

Abstract
========

This GLEP defines the procedure of a ‘general resolution’ that can
be used by developers to enforce Council's responsibility towards their
electorate.  The general resolution can be used to overrule a Council
decision or disband the Council with a 2:1 majority vote of all
developers.


Motivation
==========

The GLEP 39 metastructure defines the Council as an elected body
of Gentoo developer representatives.  The Council decides on global
issues and handles appeals from disciplinary actions.  While the Council
should naturally represent their electorate, the metastructure does not
define a precise way of exercising this responsibility.  [#GLEP39]_

In the past, a few developers have expressed their dissatisfaction with
some of the Council decisions.  However, the Council members lacked
a good way of determining whether those opinions expressed the feelings
of the majority of developers, or were limited to a small group.
At the same time, disagreeing developers had no way of answering
the same question without raising inevitable hostility between
developers.

This GLEP aims to introduce a mechanism of a ‘general resolution’ that
can be used by developers to override Council decisions, or initiate
a vote of no confidence against the Council.  This introduces a clear
method of expressing and verifying disagreement with the proceedings
of the Council at any point during its term.

This mechanism is inspired by the ‘general resolution’ defined
by the Debian Constitution [#DEBIAN-CONSTITUTION]_.  It has been
originally suggested by Matthias Maier [#MAIER-20180403]_.


Specification
=============

Possible subjects for a general resolution
------------------------------------------

The general resolution provides for the following possibilities:

1. Overruling (voiding) any Council decision, provided that:

   a. the Council decision in question is final (i.e. a general
      resolution can not be used to bypass the Council),

   b. the decision can be made without disclosing any information that
      is considered confidential (e.g. appeals of disciplinary actions
      cannot be the subject of a general resolution).

2. Initiating a vote of no confidence against Council members, resulting
   in a new Council election.


Formal procedure of a general resolution
----------------------------------------

The general resolution mechanism is defined as follows:

1. A Gentoo developer (or a group of Gentoo developers) defines
   the subject of the general resolution --- the specific motion
   to void, or other request as defined in the previous section.

2. The requestor gathers initial support for their proposal.  In order
   for general resolution vote to be possible, the request needs to
   be supported by *N1* developers.  Developers second the request
   by stating their approval along with the subject of the general
   resolution.  This shall happen in text form with an OpenPGP-signed
   e-mail sent to the original requestor.

3. Once the signed approvals of *N1* developers are collected,
   the requestor sends a ‘Request for a general resolution’
   to the gentoo-project mailing list.  The request shall include
   the subject of the resolution, all signed approvals
   from the seconding developers, and a rationale for further
   discussion.  The discussion is open for at least two weeks.

4. The elections project shall confirm that all formal requirements
   for a general resolution are fulfilled, and shall state a timeline
   for voting.  The voting period shall start no sooner than two weeks
   after the request, and shall last for two weeks.  All active Gentoo
   developers at the time when the request is published on the mailing
   list are eligible to vote.

5. The developers vote on the motion of the general resolution.
   In order for the motion to pass, it must result in a ratio
   of positive to negative votes of at least 2:1.  Additionally,
   the number of positive votes must be at least *N2*.

The developer counts are initially defined as:

- *N1*: 2 times the square root of the number of active Gentoo
  developers,

- *N2*: one fourth of active Gentoo developers but no less than *N1*.

The numbers are not rounded.  All quorums are defined as ‘no less than’.


Rationale
=========

Limitations in subject
----------------------

The main purpose of the general resolution mechanism is to provide a way
for developers to overrule Council decisions or to disband the Council
whenever necessary.  It is not meant to be used as a regular procedure
for making decisions.  Its limitations and the procedure has been
specifically designed to focus on that.

Most notably, only final Council decisions can be overruled
via a general resolution.  This aims to prevent developers
from attempting to bypass the Council and abuse the general resolution
as a generic decision-making process.  Furthermore, for simplicity
the general resolution does not provide means to alter the motion
or make a new one --- it only provides for voiding
the previously-approved motion.

The general resolution involves a vote of all developers.  For this
reason, it is essential that all developers know the rationale
for the request and have access to all the data.  This is why
the process involves a public discussion prior to the vote, and why it
can't be used for the purposes of cancelling disciplinary actions.
If developers believe that the Council is unjustly rejecting
disciplinary action appeals, they can request the vote of no confidence.

The alternative option of a vote of no confidence is provided for
the case when developers believe that Council members are repeatedly
neglecting their duty towards the developers.  This option makes it
possible to disband the Council mid-term and run a new Council election.
If the vote of no confidence passes, the Council members lose their
seats immediately and there is no Council until the election finishes.


Limitations in procedure
------------------------

Since the general resolution requires a vote of all developers, this
GLEP provides further procedural restrictions in order to prevent
developers from abusing the process to repeatedly call all-developer
votes.

Most notably, the general resolution vote can be called only
if the required number of developers second the motion first.  It is
recommended that the initial support is collected via private channels,
to avoid creating unnecessary peaks of ‘me too’ traffic on the Gentoo
mailing lists.  OpenPGP signatures are used to confirm the authenticity
of developer support; the signed messages are required to contain
the original motion in order to prevent reusing earlier approvals
for a new motion.

The minimal number of developers initially supporting the general
resolution has been selected to prevent abuse by small groups
of developers while making it possible to actually collect support
for justified use of general resolution.

The 2:1 majority of votes requirement, as well as quorum, also mean
to discourage developers from trying to abuse the process.  Since
the decisions made this way indicate serious accusations towards
the Council members, it is important that they are actually supported
by significant population of developers.

The quorum (*N2*, defined as one fourth of active developers) is
intentionally lower than the turnout at the recent Council elections
(39% in 2017, 37% in 2016).  It is defined in terms of positive votes
in order to satisfy the criterium of monotonicity (i.e. prevent ‘no’
votes from helping the motion to pass).


The numbers in practice
-----------------------

Let's assume the developer count to be 200 active developers.

*N1* is defined as twice the square root of 200 then which equals
approximate 28.3 developers.  Therefore, in order to call for general
resolution one does need the support of 29 developers.  The number does
not grow quick with new developers being admitted — it would be 34.6
for 300 developers, 40 for 400 developers.

*N2* is defined as one fourth of active developers, and the majority
of votes is defined as 2:1.  This means that for a motion to pass, it
must be approved by at least 50 active developers, with no more than
25 developers actively opposing it.  For every developer voting ‘no’
above the 25, at least two developers need to vote ‘yes’ for the motion
to pass.


Example procedure of a general resolution
-----------------------------------------

Let's consider the following example.  On 2018-02-30 the Council has
passed a motion that changed the default init system for Gentoo
to systemd.  The developer community at large seems to disagree with
this decision.  The developer community consists of 200 developers.

One of the developers puts forward the following subject:

  Void the 2018-02-30 Council decision regarding changing the default
  init system to systemd.

He finds 28 other developers who disagree with the Council decision,
and sends this text to them.  They add a cleartext signature to it,
and send it back.  He adds his own signed subject, and prepares a text
file with 29 signed subjects.

At this point, he sends the following mail to gentoo-project:

  Dear developer community,

  I would like to call for a general resolution regarding the following
  subject:

    Void the 2018-02-30 Council decision regarding changing the default
    init system to systemd.

  I believe this was a very bad decision because ...

He appropriately attaches the signed approvals as a text file to
the mail.  At this point, the discussion on the topic can begin.

A member of elections project notices the request and starts processing
it.  First he determines the cutoff date for the vote and creates
an appropriate list of eligible developers.  He downloads the signed
approvals and uses GnuPG to verify all the signatures.  Afterwards, he
confirms that the keys used match the fingerprints of 29 distinct
developers at the cutoff date.

The elections project member sets up vote for the presented subject
to start two weeks from the initial mail.  He sends a reply
to the original post with the schedule and voting instructions.

Once the voting period is over, the elections project collect results.
They are as follows:

* 74 developers voted ‘yes’,
* 37 developers voted ‘no’,
* remaining developers either abstained or did not vote.

Firstly, the quorum is verified.  In this instance, 50 ‘yes’ votes are
required to satisfy the quorum.  Since 74 developers have voted ‘yes’,
the quorum is satisfied.

Secondly, the ratio is verified.  Since 37 developers have voted ‘no’,
there needs to be at least 74 ‘yes’.  Since exactly 74 developers have
voted ‘yes’, the motion passes.

The Council decision is void then.  The previous default init system
is restored.


Backwards Compatibility
=======================

n/a


Reference Implementation
========================

n/a


References
==========

.. [#GLEP39] GLEP 39: An "old-school" metastructure proposal with
   "boot for being a slacker"
   (https://www.gentoo.org/glep/glep-0039.html)

.. [#DEBIAN-CONSTITUTION] Debian Constitution
   (https://www.debian.org/devel/constitution.en.html)

.. [#MAIER-20180403] Matthias Maier, Re: [gentoo-project] Call for
   agenda items - Council meeting 2018-04-08
   (https://archives.gentoo.org/gentoo-project/message/973be0a662b3cc74aa118a1128dcac9e)


Copyright
=========
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.


-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Rich Freeman]

On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@gentoo.org> wrote:
>
>    a. the Council decision in question is final (i.e. a general
>       resolution can not be used to bypass the Council),

One question that this brings up in my mind is the duration of these
decisions, because Council decisions are never really final.  The
Council can override its own decisions, or the decision of a prior
Council.

Presumably you wouldn't want the current Council to be able to
override a GR, but how about a subsequent one?  A lot of decisions are
made on the basis of some context that could change.

To use your example, suppose there is a GR to make OpenRC the default
service manager.  Great.  What happens in 10 years when it makes sense
to make some new service manager the default?  Normally such a
decision wouldn't even require a Council vote, but if the previous GR
has no expiration, then does that mean that another GR is required to
make a decision that may not be as controversial in the future?

To use a different example, consider GLEP 39.  Many consider GLEP 39
to be special and one that the Council cannot modify, but on the flip
side there is currently no real defined process for changing it.
(Perhaps GRs will become such a mechanism.)  The result is that
sometimes changes that might make sense don't really get considered
because nobody feels empowered to make it happen.

In any case, my point is mainly that the GR GLEP ought to indicate one
way or another how a GR can be modified.  Presumably a GR can always
be used to modify a previous GR.  However, do we want to relax things
further, such as by allowing GRs to be overriden by Council if there
has been a Council election in the interim?

My last comment is more philosophical.  I do support the concept
behind this, but I do want to note that it is a lot easier to vote for
something to happen than to actually make it happen.  If devs
consistently vote for Council members who support position A, but then
vote via GR to impose position NOT A, it creates a bit of
organizational schizophrenia as there really is no executive process
to appeal council decisions and thus you end up tasking people to
execute a policy they don't actually agree with, as volunteers.  The
likely result will be half-hearted at best, even if no outright
defiance takes place.  So, this is a mechanism that will need to be
used carefully, but I think having it available as a recourse is
better than not having it available.

-- 
Rich

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Aaron Bauman]

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

On Thursday, June 28, 2018 1:24:27 PM EDT Rich Freeman wrote:
> On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@gentoo.org> wrote:
> >    a. the Council decision in question is final (i.e. a general
> >    
> >       resolution can not be used to bypass the Council),
> 
> One question that this brings up in my mind is the duration of these
> decisions, because Council decisions are never really final.  The
> Council can override its own decisions, or the decision of a prior
> Council.
> 

By this logic then nothing is final.  We might as well throw it all away.

> Presumably you wouldn't want the current Council to be able to
> override a GR, but how about a subsequent one?  A lot of decisions are
> made on the basis of some context that could change.
> 

A subsequent one?  Like a subequent council being allowed to override a GR?  
It is my impression that the GR is not "overridable" because it is a developer 
wide vote.  The important people are the developers...

> To use your example, suppose there is a GR to make OpenRC the default
> service manager.  Great.  What happens in 10 years when it makes sense
> to make some new service manager the default?  Normally such a
> decision wouldn't even require a Council vote, but if the previous GR
> has no expiration, then does that mean that another GR is required to
> make a decision that may not be as controversial in the future?
> 

A council vote should *absolutely* be required to change the default service 
manager.  Of course, we know in practice this has been addressed by having 
different flavors of stage3 tarballs for the user.  Continuing on though, this 
is a part of the *technical* direction that the council should provide.

Also, it has far-reaching impacts by doing something like this.  We have seen 
individuals transition to Gentoo because we gave them a choice of service 
manager! (It would not be a bad idea to consider a poll across the developer 
community for a situation like this as well).

The GR GLEP, as Michał has written it, does indeed not have an expiration 
date.  The assumption you have made here worries me though.  We *cannot* 
legislate common sense.  By the developer community enacting the general 
resolution it is nullifying that particular decision.  The controls of which 
are clearly outlined.

A subsequent council would simply propose another vote to change the default 
service manager when the time is appropriate.  It should be clear as to why 
the GR was enacted (which is detailed in the GLEP) and it should be clear to 
any subsequent voting members what issues the *developers* had with it.  An 
attempt to try and pass it again with all circumstances the same would be 
ignorant.  Civil discourse is important.

> To use a different example, consider GLEP 39.  Many consider GLEP 39
> to be special and one that the Council cannot modify, but on the flip
> side there is currently no real defined process for changing it.
> (Perhaps GRs will become such a mechanism.)  The result is that
> sometimes changes that might make sense don't really get considered
> because nobody feels empowered to make it happen.
> 

I don't see why the developer community cannot change GLEP 39 if they so chose 
too.  Just no one has wanted to do it.

> In any case, my point is mainly that the GR GLEP ought to indicate one
> way or another how a GR can be modified.  Presumably a GR can always
> be used to modify a previous GR.  However, do we want to relax things
> further, such as by allowing GRs to be overriden by Council if there
> has been a Council election in the interim?
> 

No.  The point of the GR is to override council.  Not the opposite.  So, 
please see the previous paragraphs I wrote above.  It nullifies a particular 
decision.  The new council will simply try to pass something new or modified to 
fit the needs of the community.

> My last comment is more philosophical.  I do support the concept
> behind this, but I do want to note that it is a lot easier to vote for
> something to happen than to actually make it happen.  If devs
> consistently vote for Council members who support position A, but then
> vote via GR to impose position NOT A, it creates a bit of
> organizational schizophrenia as there really is no executive process
> to appeal council decisions and thus you end up tasking people to
> execute a policy they don't actually agree with, as volunteers.  The
> likely result will be half-hearted at best, even if no outright
> defiance takes place.  So, this is a mechanism that will need to be
> used carefully, but I think having it available as a recourse is
> better than not having it available.

We cannot possibly know what every person will do when they are elected to the 
council.  Furthermore, we cannot possibly know what issues may arise.  This is 
one of the reasons I have decided to *not* write a manifesto.  Let my fellow 
developers ask me questions important to *them*.  This provides a better 
measurement of how I may or may not vote.

To enact a GR requires a significant amount of developers to agree on a matter.  
This is the litmus test to address any potential "schizophrenic" like 
scenarios from happening.  Once again, you cannot legislate common sense and I 
would venture to say that this is often why a majority or similair approach is 
done.  If I can get a group of people to agree upon something then I can be 
*somewhat* sure it is a sane thing.

You mean like a policy to enable whitelisting on the gentoo-dev mailing list? 
I am quite sure Antarus was not happy to do that as he publicly stated in many 
forums.  While we may be volunteers we still must honor the roles individuals 
hold within the ecosystem.

Please *stop* using the volunteer thing as a crutch.

-Aaron

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Rich Freeman]

On Thu, Jun 28, 2018 at 3:03 PM Aaron Bauman <bman@gentoo.org> wrote:
>
> On Thursday, June 28, 2018 1:24:27 PM EDT Rich Freeman wrote:
> > On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@gentoo.org> wrote:
> > >    a. the Council decision in question is final (i.e. a general
> > >
> > >       resolution can not be used to bypass the Council),
> >
> > One question that this brings up in my mind is the duration of these
> > decisions, because Council decisions are never really final.  The
> > Council can override its own decisions, or the decision of a prior
> > Council.
> >
>
> By this logic then nothing is final.  We might as well throw it all away.

Finality has nothing to do with throwing stuff away.  Decisions are
made at a point in time.  They aren't generally discarded lightly, but
they also aren't clung to when they no longer make sense.  That is all
I'm getting at.

> It is my impression that the GR is not "overridable" because it is a developer
> wide vote.  The important people are the developers...

Great.  Then write that into the GLEP so that is clear.  My whole
point is that we shouldn't have to rely on your "impression."

> A council vote should *absolutely* be required to change the default service
> manager.

Sounds like you'll be needing another GLEP then.  What other decisions
should explicitly require Council votes?

GLEP 39 only requires them when there are disagreements between
projects.  In the absence of disagreement between projects, no Council
votes are required.

> The GR GLEP, as Michał has written it, does indeed not have an expiration
> date.  The assumption you have made here worries me though.  We *cannot*
> legislate common sense.  By the developer community enacting the general
> resolution it is nullifying that particular decision.  The controls of which
> are clearly outlined.

I'm not sure what "assumption" I've made here.  I've simply pointed
out that nothing in the policy states how a GR is to be reversed.  I
then proposed scenarios for how that could cause questions to come up.
My goal is to make the policy less ambiguous.

> A subsequent council would simply propose another vote to change the default
> service manager when the time is appropriate.  It should be clear as to why
> the GR was enacted (which is detailed in the GLEP) and it should be clear to
> any subsequent voting members what issues the *developers* had with it.

If there is no longer any controversy over the new decision (which
might be many years later), why require an all-dev vote?  And of
course a GR can always be used to re-override the Council decision if
necessary.  Obviously you'd want some controls on this so that we
don't end up with the same issues being re-voted upon repeatedly.

> > To use a different example, consider GLEP 39.  Many consider GLEP 39
> > to be special and one that the Council cannot modify, but on the flip
> > side there is currently no real defined process for changing it.
> > (Perhaps GRs will become such a mechanism.)  The result is that
> > sometimes changes that might make sense don't really get considered
> > because nobody feels empowered to make it happen.
> >
>
> I don't see why the developer community cannot change GLEP 39 if they so chose
> too.  Just no one has wanted to do it.

Probably because it is a hassle with no defined process.  I'm pointing
out that a GR could turn into a similar hassle.  Ok, a decision no
longer makes sense, but it is so painful to change that we just live
with it.  After all, a new GR requires collecting a bunch of GPG
signatures/etc, even if all the devs and the Council agree with it.
Or should the GR GLEP include a way for the Council to kick off a GR
without the need for the requisite number of individual votes?  Maybe
offer that as another option - the Council can initiate a GR with a
majority vote?

Again, my goal here is to improve the GLEP.  It isn't some kind of
objection to the concept.

> > In any case, my point is mainly that the GR GLEP ought to indicate one
> > way or another how a GR can be modified.  Presumably a GR can always
> > be used to modify a previous GR.  However, do we want to relax things
> > further, such as by allowing GRs to be overriden by Council if there
> > has been a Council election in the interim?
> >
>
> No.  The point of the GR is to override council.  Not the opposite.  So,
> please see the previous paragraphs I wrote above.  It nullifies a particular
> decision.  The new council will simply try to pass something new or modified to
> fit the needs of the community.

Presumably they can't pass something new or modified if it is related
to an existing GR, because that would be overriding a GR, which you
don't think ought to be allowed, even if it does better fit the needs
of the community.

If the Council wanted to pass something new or modified they'd need to
propose it as a new GR.  As such, the GRs really should be able to
stand on their own without tweaking, because they're going to be hard
to tweak.

> Please *stop* using the volunteer thing as a crutch.

Not sure where I ever suggested that being a volunteer excused
non-compliance with policy.  I simply pointed out that volunteers may
not be enthusiastic about doing things they disagree with.  That is
just reality.  It certainly shapes Council decisions, as it ought to.
And again it was more of a philosophical point than a defect that
needed to be addressed.

-- 
Rich

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Aaron Bauman]

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

On Thursday, June 28, 2018 3:33:24 PM EDT Rich Freeman wrote:
> On Thu, Jun 28, 2018 at 3:03 PM Aaron Bauman <bman@gentoo.org> wrote:
> > On Thursday, June 28, 2018 1:24:27 PM EDT Rich Freeman wrote:
> > > On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@gentoo.org> wrote:
> > > >    a. the Council decision in question is final (i.e. a general
> > > >    
> > > >       resolution can not be used to bypass the Council),
> > > 
> > > One question that this brings up in my mind is the duration of these
> > > decisions, because Council decisions are never really final.  The
> > > Council can override its own decisions, or the decision of a prior
> > > Council.
> > 
> > By this logic then nothing is final.  We might as well throw it all away.
> 
> Finality has nothing to do with throwing stuff away.  Decisions are
> made at a point in time.  They aren't generally discarded lightly, but
> they also aren't clung to when they no longer make sense.  That is all
> I'm getting at.
> 
> > It is my impression that the GR is not "overridable" because it is a
> > developer wide vote.  The important people are the developers...
> 
> Great.  Then write that into the GLEP so that is clear.  My whole
> point is that we shouldn't have to rely on your "impression."
> 

It is clear.  It is understood.  If you have an issue with it then send mgorny 
a patch.  As stated, it nullifies a particular decision.  Plain and simple.

> > A council vote should *absolutely* be required to change the default
> > service manager.
> 
> Sounds like you'll be needing another GLEP then.  What other decisions
> should explicitly require Council votes?
> 

"Global issues".  Again, we can't legislate common sense.

> GLEP 39 only requires them when there are disagreements between
> projects.  In the absence of disagreement between projects, no Council
> votes are required.
> 

Looks like you need to read GLEP39 again.  The word agreement isn't even found 
in it. (Hint: "Global issues will be decided by an elected Gentoo council.")

> > The GR GLEP, as Michał has written it, does indeed not have an expiration
> > date.  The assumption you have made here worries me though.  We *cannot*
> > legislate common sense.  By the developer community enacting the general
> > resolution it is nullifying that particular decision.  The controls of
> > which are clearly outlined.
> 
> I'm not sure what "assumption" I've made here.  I've simply pointed
> out that nothing in the policy states how a GR is to be reversed.  I
> then proposed scenarios for how that could cause questions to come up.
> My goal is to make the policy less ambiguous.
> 

It doesn't *need* to be reversed.  It is a nullification of a decision because 
of disagreement by the developer community.  So, the council should react by 
trying something that is "in line" with the issues that were brought up.  
Plain and simple.

> > A subsequent council would simply propose another vote to change the
> > default service manager when the time is appropriate.  It should be clear
> > as to why the GR was enacted (which is detailed in the GLEP) and it
> > should be clear to any subsequent voting members what issues the
> > *developers* had with it.
> If there is no longer any controversy over the new decision (which
> might be many years later), why require an all-dev vote?  And of
> course a GR can always be used to re-override the Council decision if
> necessary.  Obviously you'd want some controls on this so that we
> don't end up with the same issues being re-voted upon repeatedly.
> 

No, the council just proposes a new/modified proposal to vote on.  This should 
have been a product of civil discourse.  Understanding what the issues were 
and addressing them.

e.g. "The developer community believes service manager X goes against Gentoo 
principals."

Council: "Ok, here is a modified proposal addressing this concern"

> > > To use a different example, consider GLEP 39.  Many consider GLEP 39
> > > to be special and one that the Council cannot modify, but on the flip
> > > side there is currently no real defined process for changing it.
> > > (Perhaps GRs will become such a mechanism.)  The result is that
> > > sometimes changes that might make sense don't really get considered
> > > because nobody feels empowered to make it happen.
> > 
> > I don't see why the developer community cannot change GLEP 39 if they so
> > chose too.  Just no one has wanted to do it.
> 
> Probably because it is a hassle with no defined process.  I'm pointing
> out that a GR could turn into a similar hassle.  Ok, a decision no
> longer makes sense, but it is so painful to change that we just live
> with it.  After all, a new GR requires collecting a bunch of GPG
> signatures/etc, even if all the devs and the Council agree with it.
> Or should the GR GLEP include a way for the Council to kick off a GR
> without the need for the requisite number of individual votes?  Maybe
> offer that as another option - the Council can initiate a GR with a
> majority vote?
> 

What? The council can initiate GR to overrule itself?

> Again, my goal here is to improve the GLEP.  It isn't some kind of
> objection to the concept.
> 
> > > In any case, my point is mainly that the GR GLEP ought to indicate one
> > > way or another how a GR can be modified.  Presumably a GR can always
> > > be used to modify a previous GR.  However, do we want to relax things
> > > further, such as by allowing GRs to be overriden by Council if there
> > > has been a Council election in the interim?
> > 
> > No.  The point of the GR is to override council.  Not the opposite.  So,
> > please see the previous paragraphs I wrote above.  It nullifies a
> > particular decision.  The new council will simply try to pass something
> > new or modified to fit the needs of the community.
> 
> Presumably they can't pass something new or modified if it is related
> to an existing GR, because that would be overriding a GR, which you
> don't think ought to be allowed, even if it does better fit the needs
> of the community.
> 

You didn't read what I wrote.

> If the Council wanted to pass something new or modified they'd need to
> propose it as a new GR.  As such, the GRs really should be able to
> stand on their own without tweaking, because they're going to be hard
> to tweak.
> 
> > Please *stop* using the volunteer thing as a crutch.
> 
> Not sure where I ever suggested that being a volunteer excused
> non-compliance with policy.  I simply pointed out that volunteers may
> not be enthusiastic about doing things they disagree with.  That is
> just reality.  It certainly shapes Council decisions, as it ought to.
> And again it was more of a philosophical point than a defect that
> needed to be addressed.

You do often.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Michał Górny]

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

W dniu czw, 28.06.2018 o godzinie 13∶24 -0400, użytkownik Rich Freeman
napisał:
> On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@gentoo.org> wrote:
> > 
> >    a. the Council decision in question is final (i.e. a general
> >       resolution can not be used to bypass the Council),
> 
> One question that this brings up in my mind is the duration of these
> decisions, because Council decisions are never really final.  The
> Council can override its own decisions, or the decision of a prior
> Council.

The meaning of this is explained in the parentheses, so please stop
trying to bend it.  The only thing it means is that you can't call a GR
to pass a motion that didn't go through the Council vote yet.

> 
> Presumably you wouldn't want the current Council to be able to
> override a GR, but how about a subsequent one?  A lot of decisions are
> made on the basis of some context that could change.

There's no explicit necessity to impose additional restrictions
on further Council actions.  Trying to define them correctly would make
the GLEP unnecessarily complex, not to mention it'd probably end up
being imperfect.  Instead, think of GR as a penalty card.

When Council makes an apparently bad decision, the developers can give
it a yellow card.  The Council is still in the game and can technically
can do the same thing again -- however, it has been given an explicit
warning, so I don't think we really need to consider it carelessly
passing the same motion again.

What can happen (and shouldn't be blocked) is that the Council
reconsiders, gathers wider feedback and passes a different motion that's
more suitable to developers.  Or the same or future Council reconsiders
this at some point in the future.

Of course, this means that technically Council could ignore the GR
and pass the same motion again.  However, if that actually happens,
they can expect immediate GR on disbanding the Council.

> 
> To use your example, suppose there is a GR to make OpenRC the default
> service manager.  Great.  What happens in 10 years when it makes sense
> to make some new service manager the default?  Normally such a
> decision wouldn't even require a Council vote, but if the previous GR
> has no expiration, then does that mean that another GR is required to
> make a decision that may not be as controversial in the future?

As said above, the same or future Council can pass the same or similar
motion at any point in the future.

> 
> To use a different example, consider GLEP 39.  Many consider GLEP 39
> to be special and one that the Council cannot modify, but on the flip
> side there is currently no real defined process for changing it.
> (Perhaps GRs will become such a mechanism.)  The result is that
> sometimes changes that might make sense don't really get considered
> because nobody feels empowered to make it happen.

No.  The GLEP repeats that multiple times: GR is not a generic voting
mechanism but a failsafe.  I'd say calling for a global developer vote
is within Council's regular powers, and it's entirely outside the scope
of this GLEP.

> In any case, my point is mainly that the GR GLEP ought to indicate one
> way or another how a GR can be modified.  Presumably a GR can always
> be used to modify a previous GR.  However, do we want to relax things
> further, such as by allowing GRs to be overriden by Council if there
> has been a Council election in the interim?

It really seems that you didn't understand the GLEP, and instead started
processing with your own vision of GR that's not related to my proposal.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Rich Freeman]

On Thu, Jun 28, 2018 at 4:08 PM Aaron Bauman <bman@gentoo.org> wrote:
>
> It is clear.  It is understood.  If you have an issue with it then send mgorny
> a patch.  As stated, it nullifies a particular decision.  Plain and simple.
>

If it ONLY nullifies a decision, then basically the result is the
status quo before any decision was made.

> It doesn't *need* to be reversed.  It is a nullification of a decision because
> of disagreement by the developer community.  So, the council should react by
> trying something that is "in line" with the issues that were brought up.
> Plain and simple.

So your proposed workflow is:

Council approves A.

Devs object to A.  Devs perform GR.  A is unapproved.

Council approves B.

At that point Devs are then free to do another GR?  If we're going to
the trouble to nullify a decision, wouldn't we want to decide what
goes in its place?

The only thing the GR would convey is that A is unacceptable.
Certainly there would be a bazillion list posts talking about why
various individuals think A is unacceptable, but that doesn't really
tell anybody what factions might exist and what compromise might be
accepted by a majority.

> No, the council just proposes a new/modified proposal to vote on.  This should
> have been a product of civil discourse.  Understanding what the issues were
> and addressing them.

Well, presumably that would have been done the first time.  And
nothing stops them from just proposing the same thing that was struck
down, with or without modification.

>
> e.g. "The developer community believes service manager X goes against Gentoo
> principals."
>
> Council: "Ok, here is a modified proposal addressing this concern"

How would you know what the concern actually is, if the only thing the
developers all voted on was that they didn't like the original
decision?

>
> What? The council can initiate GR to overrule itself?
>

So, my statement was based on thinking that the GR wasn't just
rejecting a decision, but making a new decision of its own.  Most of
my subsequent comments do not apply if all it does is reject
decisions.

> >
> > Not sure where I ever suggested that being a volunteer excused
> > non-compliance with policy.  I simply pointed out that volunteers may
> > not be enthusiastic about doing things they disagree with.  That is
> > just reality.  It certainly shapes Council decisions, as it ought to.
> > And again it was more of a philosophical point than a defect that
> > needed to be addressed.
>
> You do often.

Citation?  And maybe save pontificating over it for a thread when I'm
actually doing it?

-- 
Rich

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Rich Freeman]

On Thu, Jun 28, 2018 at 4:32 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> W dniu czw, 28.06.2018 o godzinie 13∶24 -0400, użytkownik Rich Freeman
> napisał:
> > On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@gentoo.org> wrote:
> > >
> > >    a. the Council decision in question is final (i.e. a general
> > >       resolution can not be used to bypass the Council),
> >
> > One question that this brings up in my mind is the duration of these
> > decisions, because Council decisions are never really final.  The
> > Council can override its own decisions, or the decision of a prior
> > Council.
>
> The meaning of this is explained in the parentheses, so please stop
> trying to bend it.  The only thing it means is that you can't call a GR
> to pass a motion that didn't go through the Council vote yet.

I was not suggesting that this meaning wasn't plain.  I was just
saying that no Council decision is final as a way to bring up the
topic of duration/etc.  I'm not proposing changing the wording of this
part of the GLEP.

> When Council makes an apparently bad decision, the developers can give
> it a yellow card.  The Council is still in the game and can technically
> can do the same thing again -- however, it has been given an explicit
> warning, so I don't think we really need to consider it carelessly
> passing the same motion again.

Sure, that makes sense, and that wasn't actually what I got out of it
the first time.  I just assumed this was a way to just do direct
democracy, and not merely a way to strike down an individual decision.

> No.  The GLEP repeats that multiple times: GR is not a generic voting
> mechanism but a failsafe.  I'd say calling for a global developer vote
> is within Council's regular powers, and it's entirely outside the scope
> of this GLEP.

Ok, that wasn't what I thought you were proposing, and I think that
makes more sense.

>
> It really seems that you didn't understand the GLEP, and instead started
> processing with your own vision of GR that's not related to my proposal.
>

Indeed.

-- 
Rich

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 3009 bytes --]

On 28/06/18 18:24, Rich Freeman wrote:
> On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@gentoo.org> wrote:
>>    a. the Council decision in question is final (i.e. a general
>>       resolution can not be used to bypass the Council),
> One question that this brings up in my mind is the duration of these
> decisions, because Council decisions are never really final.  The
> Council can override its own decisions, or the decision of a prior
> Council.
>
> Presumably you wouldn't want the current Council to be able to
> override a GR, but how about a subsequent one?  A lot of decisions are
> made on the basis of some context that could change.
>
> To use your example, suppose there is a GR to make OpenRC the default
> service manager.  Great.  What happens in 10 years when it makes sense
> to make some new service manager the default?  Normally such a
> decision wouldn't even require a Council vote, but if the previous GR
> has no expiration, then does that mean that another GR is required to
> make a decision that may not be as controversial in the future?
>
> To use a different example, consider GLEP 39.  Many consider GLEP 39
> to be special and one that the Council cannot modify, but on the flip
> side there is currently no real defined process for changing it.
> (Perhaps GRs will become such a mechanism.)  The result is that
> sometimes changes that might make sense don't really get considered
> because nobody feels empowered to make it happen.
>
> In any case, my point is mainly that the GR GLEP ought to indicate one
> way or another how a GR can be modified.  Presumably a GR can always
> be used to modify a previous GR.  However, do we want to relax things
> further, such as by allowing GRs to be overriden by Council if there
> has been a Council election in the interim?
>
> My last comment is more philosophical.  I do support the concept
> behind this, but I do want to note that it is a lot easier to vote for
> something to happen than to actually make it happen.  If devs
> consistently vote for Council members who support position A, but then
> vote via GR to impose position NOT A, it creates a bit of
> organizational schizophrenia as there really is no executive process
> to appeal council decisions and thus you end up tasking people to
> execute a policy they don't actually agree with, as volunteers.  The
> likely result will be half-hearted at best, even if no outright
> defiance takes place.  So, this is a mechanism that will need to be
> used carefully, but I think having it available as a recourse is
> better than not having it available.
>
I think its about having a mechanism *to* do something, rather than
necessarily have to use it. A bit like ComRel's existence, etc .. its
there as a Last Resort when all other methods have failed, rather than a
go-to method for causing discourse. If any such mechanism is being used
regularly (or abused) then the status quo needs re-evaluating ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Eray Aslan]

On Thu, Jun 28, 2018 at 06:14:15PM +0200, Michał Górny wrote:
> The text of a new GLEP proposal follows.  The GLEP implements a General
> Resolution mechanism based on the one in Debian; the idea was initially
> proposed by Matthias Maier [1]; however, he didn't manage to find time
> to write the GLEP.
> 
> Please review the proposed text and let me know what you think.  Please
> note that the numbers presented have been chosen arbitrarily and are up
> for discussion.
> 
> [1]:https://archives.gentoo.org/gentoo-project/message/973be0a662b3cc74aa118a1128dcac9e

Thanks for the write up.

The numbers set too high a threshold to make it almost impossible to use
GR.  Debian defaults seems sane.  Is there any particular reason we are
changing them?

-- 
Eray

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Michał Górny]

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

W dniu pią, 29.06.2018 o godzinie 08∶12 +0300, użytkownik Eray Aslan
napisał:
> On Thu, Jun 28, 2018 at 06:14:15PM +0200, Michał Górny wrote:
> > The text of a new GLEP proposal follows.  The GLEP implements a General
> > Resolution mechanism based on the one in Debian; the idea was initially
> > proposed by Matthias Maier [1]; however, he didn't manage to find time
> > to write the GLEP.
> > 
> > Please review the proposed text and let me know what you think.  Please
> > note that the numbers presented have been chosen arbitrarily and are up
> > for discussion.
> > 
> > [1]:https://archives.gentoo.org/gentoo-project/message/973be0a662b3cc74aa118a1128dcac9e
> 
> Thanks for the write up.
> 
> The numbers set too high a threshold to make it almost impossible to use
> GR.  Debian defaults seems sane.  Is there any particular reason we are
> changing them?
> 

The main difference is that Debian's GR is a generic voting mechanism
that's supposed to be used ocassionally.  Our GR is a fail-safe for
Council behaving silly or going rogue.  It's not supposed to be used
under normal circumstances.

I've chosen our numbers to be high enough to discourage attempted abuse
while making it possible to actually use GR when necessary.  Which
numbers are you specifically talking about?

If it's about N1 and N2, they may seem like many but I should point out
that after all we're talking about majority of the developers
disagreeing with the Council.

N1 being around 30 developers may seem large but it's certainly smaller
than the number of Gentoo developers actively contributing to Gentoo
every day.  I get that getting them all to sign off is cumbersome but if
there's a real reason to use GR, I'm pretty sure they'll find
the motivation to do that.

N2 being 25% developers is really small.  We're talking about all-dev
vote, so really expecting at least 25% to actively take part is a must. 
It's larger than N1 but we're talking of a vote that's handled via
voting mechanism all devs are supposed to notice.

The 2:1 majority is what Debian uses for overriding decisions of TC.
So it's certainly not larger.  In some cases Debian uses 3:1.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Eray Aslan]

On Fri, Jun 29, 2018 at 08:32:25PM +0200, Michał Górny wrote:
> I've chosen our numbers to be high enough to discourage attempted abuse
> while making it possible to actually use GR when necessary.  Which
> numbers are you specifically talking about?

N1 and N2

> N1 being around 30 developers may seem large but it's certainly smaller
> than the number of Gentoo developers actively contributing to Gentoo
> every day.  I get that getting them all to sign off is cumbersome but if
> there's a real reason to use GR, I'm pretty sure they'll find
> the motivation to do that.

GLEP: twice the square root of active developers, i.e. ~30 I guess
Debian: half the square root active developers or 5 whichever is
smaller.  So practically 6 (5+1)

And bear in mind that Debian has a lot more active developers.

> N2 being 25% developers is really small.  We're talking about all-dev
> vote, so really expecting at least 25% to actively take part is a must. 
> It's larger than N1 but we're talking of a vote that's handled via
> voting mechanism all devs are supposed to notice.

GLEP: 25%
Debian: ~10% if we take number of active developers as 200

> The 2:1 majority is what Debian uses for overriding decisions of TC.

2:1 is fine.

Getting ~30 developers to sign a petition is just not realistic.  I
doubt it will ever be done.

I feel we are back to the same differences as we did in closing the
gentoo-dev ML to the general public, namely low/no tolerance for
dissident voices.

"I know best, my way or highway" attitude is not always a bad thing in
technical matters.  However, as we have seen in the gentoo-dev ML
discussion, council decides on non-tech matters as well.

The procedure for calculating the number of active developers should
probably also be mentioned somewhere in the GLEP or perhaps referenced
if defined elsewhere.

-- 
Eray

Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution

[Michał Górny]

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

W dniu pon, 02.07.2018 o godzinie 11∶21 +0300, użytkownik Eray Aslan
napisał:
> On Fri, Jun 29, 2018 at 08:32:25PM +0200, Michał Górny wrote:
> > I've chosen our numbers to be high enough to discourage attempted abuse
> > while making it possible to actually use GR when necessary.  Which
> > numbers are you specifically talking about?
> 
> N1 and N2
> 
> > N1 being around 30 developers may seem large but it's certainly smaller
> > than the number of Gentoo developers actively contributing to Gentoo
> > every day.  I get that getting them all to sign off is cumbersome but if
> > there's a real reason to use GR, I'm pretty sure they'll find
> > the motivation to do that.
> 
> GLEP: twice the square root of active developers, i.e. ~30 I guess
> Debian: half the square root active developers or 5 whichever is
> smaller.  So practically 6 (5+1)

Council has 7 members.  A number lower than that makes no sense. 
Claiming that 6 developers represent the majority is plain wrong.

> And bear in mind that Debian has a lot more active developers.
> 
> > N2 being 25% developers is really small.  We're talking about all-dev
> > vote, so really expecting at least 25% to actively take part is a must. 
> > It's larger than N1 but we're talking of a vote that's handled via
> > voting mechanism all devs are supposed to notice.
> 
> GLEP: 25%
> Debian: ~10% if we take number of active developers as 200
> 
> > The 2:1 majority is what Debian uses for overriding decisions of TC.
> 
> 2:1 is fine.
> 
> Getting ~30 developers to sign a petition is just not realistic.  I
> doubt it will ever be done.

It is realistic that you find 30 developers if there is a serious
problem needing to be solved.  If you right front assume it is
impossible, then maybe you're wrongly presuming you're representing
the majority?

> I feel we are back to the same differences as we did in closing the
> gentoo-dev ML to the general public, namely low/no tolerance for
> dissident voices.

I'm not sure if you understand the purpose of this GLEP.  For any GR
motion to pass, the *majority* must vote for it.  It's not about letting
a minority of 'dissident voices' decide.

> "I know best, my way or highway" attitude is not always a bad thing in
> technical matters.  However, as we have seen in the gentoo-dev ML
> discussion, council decides on non-tech matters as well.

I don't see how that is relevant to the topic at hand.

> The procedure for calculating the number of active developers should
> probably also be mentioned somewhere in the GLEP or perhaps referenced
> if defined elsewhere.

The number of active developers is based on the voter list which in turn
comes from LDAP.  The date for getting this list is specified
in the GLEP.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]