Sam Hartman <hartm...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
