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

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: