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

[Alexandre Oliva <aoliva at redhat dot com>]

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

> On Tue, 2018-05-08 at 23:37 -0300, Alexandre Oliva wrote:
>> On May  8, 2018, Torvald Riegel <triegel@redhat.com> wrote:
>> 
>> > Look at the numbers we have at the moment.
>> 
>> Those "numbers" have very little to do with the advertised
>> "consensus-building community".

> For example, they show that many of our developers spoke out.  This
> isn't a 2 vs. 1 argument or anything like that.

Well, you counted 12 for removal, I count 6 against, so maybe it is?

But, really, this makes it sound as if this entire process was just a
vote, rather than the consensus building our community values so much.
Do you disagree with this assessment?

I appreciate that Carlos tried to do that and ran into walls, some of
which I built myself.  Perhaps he gave up, perhaps he just realized
there was too much heat at the moment for attempts at consensus building
to stand a chance to work and lead to some positive outcome.  I hope
it's the latter, and that, after some cooling off, the consensus
building attempt can be restarted, by him or by any other proponents of
the change.

Now that the initial conditions are restored, which was one of the
triggers for me to perceive the entire process as stacked and unjust,
I'm probably going to be able to look more a lot more cooly into
alternatives and accept compromises myself.  Earlier, I was fighting
(collective) intransigence (despite Carlos' efforts) with intransigence.
Once I perceive flexibility, I will likely respond in kind as well.  I
believe that's the way to build consensus.


>> The purpose/goal of the project is not set in stone, so if it could be
>> changed by a simple majority, or deviated from by a simple majority,
>> what recourse would GNU and the original project participants have?

> So, you do want to give more power to the "original project
> participants" than to everyone else?

Not quite.  I just wish it was clear that this is already the case, in a
way, so that people aren't so surprised and react so negatively in the
rare cases in which GNU libc is asked to take a certain step by the GNU
project.

See, throughout the discussion, you and others have often made
statements to the effect that, in the project, some are more equal than
others, to borrow Orwell's phrase.  Arguments were presented to weaken
Richard's opinions on the grounds that he's not an active developer,
that he's not a maintainer, etc.  Mine, too.  Other arguments along the
same lines were made to distinguish the weight of opinions from
occasional contributors from that of active developers and that of
official maintainers.  That's fine, but we shouldn't pretend or give
anyone the illusion that we're a community of equals.

Particularly more equal than others are GNU-appointed maintainers.  I'm
not just talking about the power to "do anything", that I've been
accused of wielding despite having strived to abide by the community
rules, but also about the commitment to represent and carry out the
interests of the GNU project.

Had Richard asked me, on behalf of the GNU project, to install a change,
I am bound by that commitment to do so, and I would have done so.

However, there's more than one way to go about it.

One is to bring the change in through the community process, seek
consensus, get it, and it's there.  It's the best possible outcome.

Another is to state "GNU demands this change, we must all obey" and put
it in.  That backfires, as we all know, and it's not the first time it
has, so this is best avoided.

Yet another is for the collective influence of the official maintainers
to softly lead the community towards the consensus desired by the GNU
project.  That's how companies control "community" projects they support
without seeming oppressive (I think that's the word I wanted when I
wrote authoritarian in my previous message in this thread), and that's a
model that works reasonably well.

The exception is when the community is so unhappy with a move that even
the collective, coordinated soft influence of the maintainers cannot
achieve the consensus desired by the project as a whole.  Uprise ensues,
and pretty much everyone loses, some more than others.

Another aspect that I feel I have to bring to the table is the fact that
GNU specifically, and the Free Software movement at large, have enemies,
and Richard's behavior is so coherent and consistent as to be easily
predictable.  It's not entirely unreasonable or far-fetched to imagine a
scenario in which one of these enemies, with perfect foresight of how
each of the players is likely to behave, proposes a change that will
lead to just the sort of tension we're going through now.

The best defense to that, IMHO, is not for us to part ways, but rather
to have a lot more clarity about the power structures that are in
effect.  It's not that they've ever been intentionally hidden, but that
they haven't been explicit in the project governance documentation may
have given people distorted ideas that are now playing against us all.

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