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

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2018-05-08 at 23:26 -0300, Alexandre Oliva wrote:
> 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?

There was debate.  For example, I'm still responding to your claims, all
across this thread.  Debate doesn't mean that people always agree with
you, or move towards your position.  Sometimes debate leads to movement,
sometimes it doesn't.  You cannot claim absence of work towards
consensus just because people disagree with you, and keep disagreeing
with you in this debate.

Working towards consensus does not mean that eventually, you will always
get your say, or get to define some percentage of the final outcome.

> > Look at this thread and all the thought-out replies and opinions.
> 
> Most of the thread was actually discussing procedure, not the subject
> matter.

How is that relevant for whether there was discussion?  Of course
general procedure requires more careful debate than that "joke".  And
you do know that removal of the "joke" was pretty obviously the right
thing to do in the opinion of most people, so why would there be more
debate?

> And at that (procedure) we don't seem to have taken steps
> towards consensus either.

We have taken steps towards trying to reach consensus, because we're
discussing this.  This doesn't mean that I can convince you or you can
convince me.

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

I'm not going to join you in trying to derail this discussion.

*Right now*, we have 12 to 3 in favor of removal.  We had enough time,
everyone was able to speak up, we had lots of debate.

Even at the time of the initial decision, there was enough time allowed
for the resolution of *significant technical disagreements*.  A 26-year
old comment simply saying "Don't remove." was taking into account -- in
all it's detail -- and considered to be insufficient.  As Carlos said at
the very beginning, maintainers rightly considered this to have
consensus at the time.  And we still have consensus.

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

I agree that the rules written down in the wiki could potentially be
much more detailed and formal.  But it doesn't change that we have a
very large and stable majority in favor of the removal.

So, if you want to improve the clarity of the rules, please do so in a
separate thread and discussion.

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

If you were unsure, you should have just discussed more with others
first.  Or listened to the guidance of your fellow GNU maintainers (eg,
Carlos).  Notice that others who use the consensus process much more
often that you do (because they are much more active in the community
than you in recent times) did not think that the process wasn't clear
enough to judge this case.

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

That's an incorrect accusation.  You can't accuse N people to have more
to say than M people, if N is much larger than M.  Specifically, please
compare the number of message you have sent vs. the number of messages
sent by others, *per person*.  If someone "shouts louder", than it's
you.  You can do similar comparisons with the number of lines written
etc.  And please also note that most messages others have been sending
recently are responses to you; elsewhere you complained that there would
be not enough debate, and now you complain that others talk to much.

For example, I just wrote 8 lines because I had to debunk on your wrong
accusations. 

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

The votes so far are 12 to 3 in favor of the removal.

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

While it may be made more clear in the wiki page describing our
consensus process, majority votes is what we have effectively used all
the time.  The notion that consensus doesn't require unanimous consent
is a majority vote.

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

"Keep in mind consensus need not be unanimous":  We have 12 to 3 in
favor of the removal.  What else do you need?
"sustained opposition to substantial issues by an important part of the
concerned interests": 3 compared to 12 is not important either, in
particular considering that for 1 of the 3, it wasn't clear whether it
was a joke, another one is a 26-year-old comment, and 1 hasn't been an
active developer in the past.  The other 12 were to large extent active
developers or GNU maintainers.

Like in the real world, not all laws are perfectly formalized.  They
evolve into a set of rules according to how things work in practice.  We
don't have courts, but if the majority of the community disagrees with
you, including other maintainers, that's a pretty good indication that
your interpretation of the consensus page might not fit the reality of
the community you want to participate in.

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

So, should RMS have the authority to overrule the community or not?  You
say the way in which he did wasn't nice, but you don't comment on
whether he should have that power or not.  And whether that will
undermine the community in your opinion.

(I'm asking because I think it will undermine, and you said that you
agree with some of that.)

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

The latter, of course.  Though even the former would clarify the current
state, I guess.

> I can't get RMS to do anything.

Sure, and that's not what I asked.

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

Well, at least that's a start for a clearer position we can argue about.

Because you spent so much time dissecting glibc's consensus rules, could
you also work towards providing the same level of detail for the rules
that specify what kind of governance GNU projects would have to endure?
For example, what do you consider hostile capture?

> It's a tricky balance to make room for the project
> to flourish while ensuring it doesn't turn against its purpose.

Frankly, that's your and RMS's problem.

IMO, you need to convince the current glibc community and its developers
that you can provide an umbrella that's worth working under, not vice
versa.  Your and RMS' recent behavior hasn't been helpful to achieve
this, IMO.

I suggest that both of you (1) let the glibc community do it's job and
continue working as it has been in the past years, and (2) concurrently
work on a clearer description of what kind of powers you'd like to
reserve for projects working under your umbrella.