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

[Aaron Bauman <bman@gentoo.org>]

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