On another list, there was discussion of the DPL encouraging the
secretary to make the vote on the rms GR secret.
On another list, there was discussion of the DPL encouraging the
secretary to make the vote on the rms GR secret.
I argued on another list that[...]
Several people agreed with me, ande one person disagreed.
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.
* 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.
That said, I think it's a *very* bad idea to change the vote procedure
during an ongoing vote. Really *bad* idea and precedence. Double more
so on a vote with shortened discussion period.
(plus secret voting is a *really really really* hard problem.)
I also don't fear that much of a changed outcome. It seems 117 Debian
people (most of them voters I believe) signed https://rms-open-letter.github.io/
and https://vote.debian.org/~secretary/gr_rms/ counts 268 valid votes,
so, based on that *and* on the discussion here now and in the past, I
don't think a few people who fear to vote what they think because then
their opinion could become public will make a big difference.
Most people
made public statements already anyway. Also: they vote has been started
as a public vote, it was shortened as a public vote and it's technically complete unclear what "secret" would mean here (and to whom and for how long).
But, to be clear, change outcome of the vote is not my concern here. Changing the way we vote, in a rush, from what will be perceived as a cabal, is my concern.
On Fri, Apr 09, 2021 at 10:59:16AM -0700, Russ Allbery wrote:
* 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.
I fear that devotee will break in various ways changing from
a non-secret to a secret in the middle of a vote. But I could
remove all processing of the results so far, and then reprocess
all the received emails. This would result in getting a new
acknowledgement (or error) mail.
On another list, there was discussion of the DPL encouraging the
secretary to make the vote on the rms GR secret.
There has been increasing harassment of people based on what they are expected to vote on the rms gr.
People on both sides have expressed increasing discomfort with the idea
of voting in public with the entire world knowing how they voted.
I argued on another list that it would be appropriate for the DPL (with
the concurrence of the secretary) to make the vote secret using
constitution section 5.1 (3).
Le vendredi, 9 avril 2021, 19.12:26 h CEST Sam Hartman a écrit :
I don't think changing our 25+ years worth of GR practice (and GR tradition) *right in the middle of a vote* will do any good; not internally, and not externally.
Do I think we should have procedures to decide _before a vote is called_ whether individual votes will be published after the vote? Absolutely; very clearly. But do I thing we should do this change for that very vote, while some votes have already been tallied, by "consensus" decision and/or pressure on the secretary? No. Clearly not.
On Fri, 09 Apr 2021 13:12:26 -0400, Sam Hartman wrote:
There has been increasing harassment of people based on what they are expected to vote on the rms gr.
People on both sides have expressed increasing discomfort with the idea
of voting in public with the entire world knowing how they voted.
I argued on another list that it would be appropriate for the DPL (with
the concurrence of the secretary) to make the vote secret using constitution section 5.1 (3).
I would like to state that I disagree with retroactively making a public
vote private. I voted with the assumption this would be a public vote
and as such, as is common on Debian GRs, I have already published my
vote.
It was very clear when the vote was called that this would be a public
vote. At that point, a number of people had already received significant harassment, so I don't believe this is a new concern.
To reduce harassment, we could possibly release the tally at a later
date, rather than immediately; say, no sooner than 3 months but no later
than one year.
I do not support making the vote private, and I do not want it to seem
like that there is consensus that it should be. If the concern is "the
entire world", I would be okay with the tally being published
internally.
Thanks Sam for raising this.
After a careful thinking, I agree with Elena's opinion and would rather
not make the vote private while it already has started.
On 10.04.21 15:33, Didier 'OdyX' Raboud wrote:
Le vendredi, 9 avril 2021, 19.12:26 h CEST Sam Hartman a crit :
I don't think changing our 25+ years worth of GR practice (and GR tradition)Reading Odyx' arguments on keeping the ballot public makes a lot of sense to me though and I'm now in favor of keeping the usual decision making
*right in the middle of a vote* will do any good; not internally, and not
processes intact, and to change the constitution later in time - if the project wishes to do so.
Hello all,
Pierre-Elliott Bécue [2021-04-10 18:16 +0200]:
After a careful thinking, I agree with Elena's opinion and would rather
not make the vote private while it already has started.
Ulrike Uhlig [2021-04-10 18:20 +0200]:
On 10.04.21 15:33, Didier 'OdyX' Raboud wrote:
Le vendredi, 9 avril 2021, 19.12:26 h CEST Sam Hartman a écrit :processes intact, and to change the constitution later in time - if the
I don't think changing our 25+ years worth of GR practice (and GR tradition)
*right in the middle of a vote* will do any good; not internally, and not >> Reading Odyx' arguments on keeping the ballot public makes a lot of sense to >> me though and I'm now in favor of keeping the usual decision making
project wishes to do so.
Thanks to the three of you -- very carefully and reasonably worded. As someone
who initially also prefered a secret vote [1] (although that was *before* voting started), I find this entirely convincing.
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:
I agree for the GR vote to be secret. I understand others came to a different conclusion. I trust Kurt for making the right decision. I
will not complain about it.
As secretary, I do not intend to make the vote secret.
Personally, I would like to see the vote secret.
I think the best way to make the vote secret is that the DPL makes a decision. We have a process that can deal with people not agreeing
with that decision.
GR public should be ashamed of dragging their fellows into denuding >themselves for no good reason.
Those who insist on making the personal views on this (non-technical!!!)
GR public should be ashamed of dragging their fellows into denuding themselves for no good reason.
VOTING SECRECY[2] Critics against one's opinion of course are.
This is a non-secret vote. After the voting period is over the details on
who voted what will be published.
Those who insist on making the personal views on this (non-technical!!!)
GR public should be ashamed of dragging their fellows into denuding
themselves for no good reason.
I am really worried that someone could say that holding to our values, respecting our processes and avoiding to create potentially
indesirable precedents is "no good reason" and grounds to be ashamed.
Hi Pierre-Elliott,
Am 11.04.21 um 14:27 schrieb Pierre-Elliott Bcue:
Those who insist on making the personal views on this (non-technical!!!) GR public should be ashamed of dragging their fellows into denuding themselves for no good reason.
I am really worried that someone could say that holding to our values, respecting our processes and avoiding to create potentially
indesirable precedents is "no good reason" and grounds to be ashamed.
I haven't seen anybody suggesting to violate our processes or alike. What I've seen is a request to make use of 5.1(3) of our constitution, but I consider that a (granted, rarely used) part of our processes.
What I see is a tension between our social contract and our code of conduct. The social contract paragraph three ("We will not hide problems") talks
about doing our business in public, yet refers to our bug reports. On the other hand our code of conduct paragraph five ("Be open") clarifies that public methods of communication are preferred, "unless posting something sensitive." Reading the many mails on this context let me think that we have a rough consensus to consider the RMS GR results something sensitive. So, I consider the publication of the vote results for this GR a violation of our code of conduct...
We haven't been in such a situation before (e.g. I am not aware of any previous GR about personal related issues), so I think we as a project need to find a balance for handling such situations in the future. Long term to
me this could mean to change our constitution, e.g. allowing secret votes also for non leader votes in the future. Yet this doesn't help in the
current situation.
Pierre-Elliott, given the current social contract and the code of conduct, would you mind to elaborate a bit how you see our processes violated by letting the current leader make use of our constitution 5.1(3) to publish
the RMS GR results as an anonymized tally sheet like in our yearly leader elections?
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.
For what I'm concerned, I don't "insist on making the personal views on this GR public", because it was always clear (to me) that all voters' personal views on this GR would end up being made public by the secretary on our website; this is how we have all experienced the publication of GR results for
at least a decade. I insist on "not changing how we collectively run through the GR experience in the middle of a sensitive GR". This is not "dragging my fellows into denuding themselves", because my expectation is that every voter is well aware that their vote would be published, in this GR as in any GR. [1]
If you don't want to (or cannot afford to) see your personal views on this
GR to be made public, then don't vote.
Don't misread me; it is a very very serious concern that external factors (threats, pression, etc) make it so that some of our voters will not vote in fear of retaliation. But I think that if we, as a project, accept to bend our traditional and constitutional procedures under that external pressure through
emergency exceptional measures, we also make the project more vulnerable to future external pressure; we also weaken this GR's results too.
We must protect our members from harassment; we must defend the project from external influence; and we must call out external pressures in the strongest terms possible. Threats against Debian project members because of their public
opinions in the project are *not acceptable*, ever [1], and we must stand, as a project, against those threatening our members and our community. The problem we face here is the pressure and the threats against project members, not the publication of the GR votes. Let's not forget that.
So I suggest the DPL directs under s5.1 something like:
"The secretary shall delay publication of the the association between identify and ballot on the tally sheet, for a period of not more than 90 days, unless directed otherwise by a General Resolution of the Developers."
A GR about future secret ballots should make provision for how to apply it retrospectively to this one. This preserves the 3:1 requirement that there would have been were it being decided in advance.
I think the best way to make the vote secret is that the DPL makes a decision. We have a process that can deal with people not agreeing
with that decision.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 237:40:11 |
| Calls: | 6,624 |
| Files: | 12,172 |
| Messages: | 5,319,874 |