Re: Making the RMS resolution a Secret Ballot
Sam Hartman <hartmans@debian.org> writes:
> Thanks for doing this. I'm actually very comfortable for us to make the
> decision under 5.1(3). We cleraly cannot hold a GR in time to change
> the constitution prior to the election ending. And our constitution
> already has a provision for making decisions where a timely decision is
> required. I think this qualifies; it is becoming more and more clear we
> need to protect people on both sides of the vote, and other avenues like
> GRs will not allow us to achieve something in time. This is not a
> situation that has become urgent through inaction on our part: as
> harassment has increased it has become more clear that action is needed.
> So while we might have been willing to let this last vote slide without
> secret ballots, it is becoming more clear through the actions of others
> that is an increasingly bad idea. So I absolutely support the DPL (with
> the secratary's concurrance) making this decision under the emergency
> powers DPL clause.
I support this approach and believe the DPL should decide under 5.1(3)
that Debian will not publish the association between identity and ballot
for the RMS resolution.
My rationale:
* Many Developers have expressed discomfort or fear about voting publicly
on this resolution. Those concerns have been expressed on all sides of
the debate, and are in the context of continued escalating harassment of
project members. We have good reasons to believe that this vote will be
used for further harassment.
* A secret ballot, while contrary to the constitution for GRs, is not
wholly irregular for the project. We use one every year for the DPL
election and the tradeoffs are well-understood. This vote poses an
additional challenge because we haven't been using the verification
method we use for DPL votes from the start of the vote, but I don't
think this is a serious enough issue to be decisive. At worst, we are
extending one-time trust to the Project Secretary that he will
accurately count the votes without normal verification processes in this
one unusual circumstance, and then will immediately return to regular
order to discuss how to handle this going forward.
* Changing the vote to a secret ballot seems to be the least drastic and
irregular action that can be taken to resolve the problem. There are
other things that we could do, such as canceling the GR in its entirety,
but anything we do here potentially sets some precedent, and this seems
like the least damaging precedent to set. A secret ballot doesn't
undermine our other constitutional provisions, whereas (for example) the
DPL canceling a GR potentially undermines the project's ability to
override the DPL.
* Switching this vote to a secret ballot is clearly a decision with a
fixed deadline (namely the voting period, since the decision for whether
to have a secret ballot will affect people's vote), and thus satisfies
the second paragraph of 5.1(3).
* There is an obvious mechanism to reject this course of action if we have
misjudged project consensus on wanting a secret ballot. Since this
decision would be a DPL action under 5.1(3), any Developer can propose a
GR to override that decision under 4.1(3). If that GR is sponsored by
2K developers, the DPL decision would be immediately put on hold, which
in this situation essentially overrides the decision given the fixed
deadline. If there are not 2K developers to override this decision
(this is not a very high bar), I think that's a reasonable (albeit not
perfect) way of gauging project agreement with this decision.
* We will be bringing a GR to resolve the question of secret ballots for
GRs going forward, so the precedent of this decision will be clearly
limited by a subsequent GR in which the whole project will have a
constitutional vote. (Obviously if that GR determines that we do not
want to have a secret ballot for subsequent GRs, future DPLs should take
that into account and not use 5.1(3) in this way again.)
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: