This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rain1 at airmail dot cc] Delete abortion joke


On May  8, 2018, Torvald Riegel <triegel@redhat.com> wrote:

> We did work towards consensus.

The only person I recall actually trying to find some middle ground or
alternative position that could be acceptable to all was Carlos (it
always amazes me how he manages to do that, hats off!).  Can you show
other examples of the "we"?

Or is your idea of "working towards consensus" for each group to
repeatedly shout its unmovable position in the hope that the other party
will be convinced or defeated by exhaustion?

> Look at this thread and all the thought-out replies and opinions.

Most of the thread was actually discussing procedure, not the subject
matter.  And at that (procedure) we don't seem to have taken steps
towards consensus either.

> If you think that tyranny of the majority is avoided by endless
> approaches to try to reach consensus, then that's tyranny of the
> minority.  That's why we say that unanimous consent is not necessary to
> reach consensus.

Yeah.  That's a slightly contradictory passage opening the rules.  It
defines consensus in a way that precludes sustained objections by
relevant parties, and then states it doesn't imply unanimity.  I
understand that's what this is about, but I think it would make more
sense to define general agreement as either (unanimous) consensus (as in
the first sentence), or, failing that, the result of a structured
procedure to override objections that can't be overcome.  Anyway...

Does it seem to you that the proposed removal "takes into account all
interests concerned", or that, before the initial patch was committed,
given the existence of at least one objection by email and another in
the comments proposed for removal, "sufficient time [was allowed] for
the discussion, negotiation and resolution of significant technical
disagreements", following "a process that involves seeking to take into
account the views of all parties concerned and to reconcile any
conflicting arguments"?

Where was success defined?  Where's the summary of participant
positions?  Where are the complaints and concerns recorded for future
use?

I get it that it says consensus needs not be unanimous, but there isn't
any guidance whatsoever as to when it might be acceptable to decide
there's consensus or general agreement despite sustained objections, or
when there was enough discussion.  I get it that these things need a lot
of wiggle room because decisions of very different complexity might need
very different parameters.  Still, some examples of acceptable and
unacceptable situations might be useful for reference.

Like, if we have 4 voices for and 1 or 2 against, is it ok to proceed
after as little as one day?  If there are some 30 voices for and 5
against?  How about 5 for and 30 against?  Do voices count the same, or
are users, occasional contributors, regular developers, appointed
maintainers and ultimate maintainers counted differently, if counting is
even relevant.

Or does it not even matter how many voices there are for, and what
really matters is whether there's a reasonable amount of opposition to a
change?

There's nothing about this in the process, and this was one of the
sources of stress for me when trying to decide whether or not installing
a proposed change was in line with the process.  The application of the
rules appears to be completely arbitrary and, in this case, it seems to
have fallen back to what position shouts louder.

At an organization I'm a part of, we also strive for consensus, but we
have a fallback voting process for when we can't reach consensus.  I'm
not suggesting we adopt something along these lines, because the
structure of the group is very different (that is a closed group), but
it might be clearer and more honest to admit that the initial definition
of consensus is NOT what we mean by consensus, or consensus-driven, and
that there are arbitrary (or democratic, or what?) fallback processes
when sustained objections remain.


>> This means that if there is opposition to a proposed change, it is up to
>> the proponent to listen to the involved parties and attempt to find
>> middle ground so that opinions converge, or at least that objections be
>> withdrawn.
>> 
>> Is that not so?

> And we tried that, and the majority and you have not changed their
> opinions.  So, given that the majority is much bigger, we follow the
> majority and move on.

Nothing like that is stated in the rules.  Per what's written, it might
seem perfectly legitimate for me to take note of the objections of the
majority and write them off, and moving forward with the position of the
minority.  That would be unusual, but it is within the written rules
AFAICT.

>> > What also happened, though, is that RMS showed up and that said that the
>> > community's consensus process wouldn't apply, that he'd have the last
>> > say, always, if he wanted, and that the arguments and opinions of a
>> > majority of the active developers don't matter.
>> > That will push people away, because it undermines the community.
>> 
>> You might be surprised that I very much agree with your perception
>> stated in the paragraph above, and also with your conclusion.  It was
>> not nice that he did so.

> So what does that mean precisely, for you?

It means he stated his authority as GNU project leader in a way that
wasn't very nice (understatement :-), and that this wasn't taken well by
many, even by those who realized this was the case, and perhaps more so
by those who did not realize it was so.  I don't have a lot of
experience with positions of authority, and I've been a disaster in the
few I've occupied, but there might be other ways to lead that don't
involve entering pissing contests and power struggles.

There might be, however, times in which the struggle is unavoidable; I
wonder if this is one of those cases.

> According to other statements by you, you still don't seem to accept
> that we are consensus-based project.  Can we actually get you and RMS
> to acknowledge that?

Acknowledge what, "we do not accept it", or "we are consensus-based
project"?

I can't get RMS to do anything.  You might be surprised, but he has a
mind of his own, just like you and I do.  He listens to ideas and
arguments presented to him, and it hardly matters who they come from.

What I can say is that it's not reasonable for GNU, or any group with a
well-defined purpose, especially political purposes, to be both open for
anyone's participation and consensus-based.  The risk of hostile capture
is too high, and the more relevant the project, the higher the risk.  At
least some lines of defense are needed against that, for the project to
remain carrying out its goals.  Being part of the GNU project, it is
just natural for GNU leadership to play such a line of defense in GNU
libc and all other GNU projects.  GNU official maintainers are another
line of defense, but historically this line of defense alone hasn't
always been enough.  It's a tricky balance to make room for the project
to flourish while ensuring it doesn't turn against its purpose.  I ain't
easy to be in Richard's shoes.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]