[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Ways forward regarding the RMS GR



Hi Debian Developers

Over the course of the last few days, I've received many mails regarding
the RMS GR, both on this list, on debian-private and in private. These
mails contain a wide spectrum of concerns and even ideas on how to
improve our situation, each of which come with their own set of upsides
and downsides.

There's been wide acknowledgement within our community that our GR
process isn't perfect, and there's been some good ideas already that
could help improve it, some might even need GRs themselves to update our
constitution towards a better GR and/or voting/polling process. In this
particular case, I feel that the process is more than just imperfect,
and that it may be failing us. While it's premature to do a full
postmortem on this GR, it's already clear where some cracks have formed
early on.

Initially, the RMS open letter[1] contained a list of individuals
supporting the removal of RMS and the existing FSF board from their
positions there. Soon after, some organisations were added and the list
of organisations grew quite fast, begging the question for some: Should
Debian also sign this letter?

[1] https://rms-open-letter.github.io/

At this stage, many Debian Developers (including myself) have signed the
letter. I felt that this was both sufficient in terms of a Debian
presence there, and in terms of what needed to be achieved with such a
letter. While I'm not scared of making a unilateral statement on behalf
of the project when needed, at the time, I just didn't feel it would be
appropriate for the DPL to unilaterally add Debian to the list of
organisations there.

Members within the project felt that we should represent Debian on that
letter more formally, and whether it's the best tool or not, the only
tool that we do have for that is the GR process, and it didn't take long
for the initial proposal[2] to be sent and be seconded[3].

[2] https://lists.debian.org/debian-vote/2021/03/msg00083.html
[3] https://www.debian.org/vote/2021/vote_002#proposer

Now, I know and acknowledge that the circumstances we find ourselves in
here are a bit extraordinary, but, even within that context, what
happened here so far was perfectly in accordance with our constitution
and the processes it mandates. The project members who wanted to ratify
the letter followed the exact procedure they were supposed to.

Although, this is also when the cracks start appearing. It seems that in
both this vote, and some previous GRs that have happened, it seemed that
a lack of metadata on the GR has hurt us.

In this case, what we're voting on has seemingly subtly, but
significantly changed since the initial proposal.

Initially, the question that the original GR proposal raised was more or
less binary in form. It basically asked, "Should we as a project sign
this letter?", which ultimately, can only end up as a yes or no option.
I say "more or less" binary, because of course, it ends up being more
complicated than that. If that option ran by itself, we'd end up with an
option on the ballot for the affirmative of the GR and for FD (Further
discussion), which in itself causes some problems, since some might
literally want further discussion on the topic, while it is also
typically used as a "None of the above" option in votes with many options.

I was comfortable reducing the discussion period on the vote, especially
since the question it poses is relatively simple (even though it might
be a difficult choice for some to make). I thought that there might have
been another option proposed option for the GR, so that the votes would
extend to the equivalent of "yes/no/FD", but didn't quite expect that
there would be additional proposals that would change the nature of the GR.

So to recap, initially the GR proposal was to ratify the RMS open
letter, which is basically (albeit with caveats) a yes/no question. With
the addition of more proposals, the question that the original poster
was asking, "Should we signed this open letter" changed to a much
broader question of "What should our public position on RMS be?". It
might sound like a subtle difference, but it's really an entirely
different kind of vote that may need a different kind of discussion
period and even a different level of timeliness. At this point, I'd like
to state that I'm not blaming any individual involved with this GR
whatsoever, for the most part, everyone did what they were supposed to
do or what they could do to get their voices heard, my problem is that
this process is really a clumsy fit when it comes to nearly any decision
other than constitutional changes or a DPL election.

The privacy aspect has brought another dimension to the problem. There
are concerns that some might not vote because this vote will be public,
and might open themselves up to further real-world harassment.
Unfortunately, our constitution doesn't seem to provide us with any
tools to deal with this, I don't think the authors at the time could
have anticipated the current social climate in the world and on the
Internet. Some people have called for this vote to be made private, and
while I 100% support that, it seems unclear if that's possible in time.
I'm in support of the secretary changing the vote to a secret vote,
although the secretary has indicated in private that he'd only be
willing to make such a change if there is consensus for that, which may
prove difficult in the remaining time that we have in this vote.

If the vote were to change to a private vote, it has also been pointed
out that it might change how some people would like to vote in this GR.
In the case that this vote would be turned into a private vote, I would
urge the secretary to extend the voting period by 72 hours and send an
initial announcement about the change, and then another reminder at the
start of the 72 hour period in addition to the usual vote reminders that
are sent.

Having said all of the above, our voting stats are public, and at the
time of writing, 327[4] people have voted for the DPL election (a
private vote) while 293[5] people have voted for the RMS GR. So even
though a significant people who could make a difference in terms of our
voting population haven't voted, at the same time, it's also a
significant proportion that have.

As for cancelling the vote, I see that as something that's a much more
severe route and that I won't be imposing as DPL. For that to happen
there would have to be significant consensus within the project that
would have to be able to convince our secretary. I doubt there's much
chance of that happening before the end of the vote.

The situation might seem bleak, but it's not completely hopeless. It's
still possible for any member to vote FD above all other options if
needed, and we can learn from this experience to improve our
decision-making mechanisms going forward.

While I certainly have my own views, agendas and biases within the
project (as does any other DD), as DPL I aim to be both transparent
about them and be fair to those with opposing views within the project.
Sometimes this has been like walking a tightrope, but I think that we
can all work together on improving our processes. Regardless of how both
our current votes turn out, I resolve to start discussions on how we
make decisions in Debian on the -project mailing list and also register
BoF sessions at future events like DebConf (or even have a dedicated
event for it, if there's enough interest). This is unlikely to be the
last tough decision that we'll have to deal with.

At the very minimum, please remember to treat other people with
civility, and even kindness. It's ok to not agree with someone, but if
you need to take someone on, do it based on their ideas that you don't
agree with, don't get personal, don't call names, don't discredit
someone based on their identity. As a project we also have some baggage
that have built up, and we're still hauling that while at the same time
navigating some difficult space. I believe that it's possible for us to
get better, let's put it to the test to what extent that is possible.

-Jonathan



Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: