On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
...
* The length of the discussion period is ill-defined in multiple ways,
which has repeatedly caused conflicts. It only resets on accepted
amendments but not new ballot options, which makes little logical sense
and constantly confuses people. There's no maximum discussion period
defined, which means fixes for that risk introducing a filibuster.
* Calling for votes is defined as a separate action from the end of the
discussion period, but in practice the constitution allows any developer >> to call for a GR vote via an abuse of process that probably wasn't
intended, and even apart from that, the set of people who can call for a >> vote is strange and not very defensible.
...
The process to shorten the discussion period is also suboptimal.
In the latest GR the way the discussion period was shortened was
perceived by many as an anti-democratic attempt to suppress discussions about the contents and alternative ballot options.
And there was plenty left to discuss (including wording of ballot
options and secrecy of the vote) when the minimum discussion period
ended and the vote was called.
I would suggest to replace the option of shortening the discussion
period with the possibility of early calling for a vote after a week
that can be vetoed by any developer within 24 hours. This would ensure
that shorter discussion periods would only happen when there is
consensus that nothing is left to be discussed.
Adrian Bunk <bunk@debian.org> writes:
On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
...
* The length of the discussion period is ill-defined in multiple ways,
which has repeatedly caused conflicts. It only resets on accepted
amendments but not new ballot options, which makes little logical sense >> and constantly confuses people. There's no maximum discussion period
defined, which means fixes for that risk introducing a filibuster.
* Calling for votes is defined as a separate action from the end of the
discussion period, but in practice the constitution allows any developer >> to call for a GR vote via an abuse of process that probably wasn't
intended, and even apart from that, the set of people who can call for a >> vote is strange and not very defensible.
...
The process to shorten the discussion period is also suboptimal.
In the latest GR the way the discussion period was shortened was
perceived by many as an anti-democratic attempt to suppress discussions about the contents and alternative ballot options.
And there was plenty left to discuss (including wording of ballot
options and secrecy of the vote) when the minimum discussion period
ended and the vote was called.
I would suggest to replace the option of shortening the discussion
period with the possibility of early calling for a vote after a week
that can be vetoed by any developer within 24 hours. This would ensure
that shorter discussion periods would only happen when there is
consensus that nothing is left to be discussed.
Would you expect a different result if that had been done in this case?
I don't think that one can automatically assume that more discussion
is better.
I genuinely think that more time preparing the ballot would have led to
fewer more well-written options on the ballot, and consequently a
higher
likelihood that Debian would have decided to make a (more well-written) statement instead of the current outcome of not making a statement.
Quoting Philip Hands (2021-04-20 11:57:58)
Adrian Bunk <bunk@debian.org> writes:
On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
...
* The length of the discussion period is ill-defined in multiple ways, >> which has repeatedly caused conflicts. It only resets on accepted
amendments but not new ballot options, which makes little logical sense
and constantly confuses people. There's no maximum discussion period >> defined, which means fixes for that risk introducing a filibuster.
* Calling for votes is defined as a separate action from the end of the >> discussion period, but in practice the constitution allows any developer
to call for a GR vote via an abuse of process that probably wasn't
intended, and even apart from that, the set of people who can call for a
vote is strange and not very defensible.
...
The process to shorten the discussion period is also suboptimal.
In the latest GR the way the discussion period was shortened was perceived by many as an anti-democratic attempt to suppress discussions about the contents and alternative ballot options.
And there was plenty left to discuss (including wording of ballot options and secrecy of the vote) when the minimum discussion period
ended and the vote was called.
I would suggest to replace the option of shortening the discussion period with the possibility of early calling for a vote after a week that can be vetoed by any developer within 24 hours. This would ensure that shorter discussion periods would only happen when there is consensus that nothing is left to be discussed.
Would you expect a different result if that had been done in this case?
I genuinely think that more time preparing the ballot would have led to fewer more well-written options on the ballot, and consequently a higher likelihood that Debian would have decided to make a (more well-written) statement instead of the current outcome of not making a statement.
On 2021-04-20 12:50, Jonas Smedegaard wrote:
I genuinely think that more time preparing the ballot would have led
to fewer more well-written options on the ballot, and consequently a higher likelihood that Debian would have decided to make a (more well-written) statement instead of the current outcome of not making
a statement.
On th other hand this leads to even more discussion, more flame-wars
and maybe some other ballots that come in in a short time before the
voting peropd starts - which might have the same issues you've just described. But without a defined time on when a vote starts, the
discussion will never end.
No idea on how to fix that, though. Personally I think having fixed
and known dates is still the best option.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 38:20:10 |
Calls: | 6,648 |
Files: | 12,193 |
Messages: | 5,329,242 |