Re: My position, and possible changes to my proposed system
Wouter Verhelst <wouter@debian.org> writes:
> First, let me clarify my position: I feel that our voting system works
> best if all the relevant options are represented on the ballot. This
> requires that all relevant options have a chance to be developed; if we
> have a system that has a hard time limit, no matter where it is set,
> then there is a chance that a relevant option would not appear on the
> ballot, which I think should be avoided as it can call into question the
> legitimacy of the ballot: if a controversial option favoured by a vocal
> minority was not represented on the ballot, the GR is not likely to
> resolve the issue, because you can be sure that minority will hammer on
> the missing option in the discussion after the GR.
I think this is a good summary of our core disagreement.
In contrast, I believe that
* adding more ballot options quickly reaches a point of diminishing
returns after the first couple of weeks, after which it does little to
reduce the controversy of the vote (in fact, it may increase the
controversy due to the extension of the discussion);
* having more ballot options is helpful to a point in increasing the
legitimacy of the outcome, but some people are going to object to the
legitimacy of any controversial vote and, if we choose to take much
longer and develop more ballot options, those complaints will shift to
questioning the legitimacy because the process took so long that people
stopped paying attention or the ballot is so confusing that we can't
trust people's votes (we already see those complaints today in a system
with a roughly equivalent deadline to what I'm setting); and
* what is lost in the meantime is representation for the people who
believe that reaching a decision in a timely fashion is significantly
more important than crafting ballot options for every position.
My goal is to strike a balance between providing enough time for people to
think carefully about the propose and produce additional options, and
having the process resolve on a timely and predictable time scale such
that it's not a horrific ordeal and it's conceivable that if we don't like
the outcome we could vote on it again.
I do think my concerns apply primarily to more controversial issues, and
some things, such as constitutional amendments like this one that require
broad project consensus, may require more time to discuss properly. But I
don't think that has to be handled directly in the formal timing; instead,
one can have a draft discussion such as the one we're having right now and
only start the process once that's complete.
I know that you're concerned with someone pre-emptively starting the
process in the middle of such a discussion. I'm not, because I think
that's how the system represents the interests of people whose objection
is not to the text but that we're taking too long to make the necessary
decision, and because, particularly for constitutional and other
super-majority votes which require the most care, a too-early GR can
easily be voted down while the more thoughtful one continues on its
original schedule (which is not modified by someone else bringing another
GR earlier).
I think we agree on a lot of other things, and I appreciate your
adaptation of your proposal to try to make it more of a compromise! But I
do think we have a core disagreement on these points and probably won't
convince each other entirely.
I think I'm convinced that your proposal limits the discussion period
sufficiently that it won't cause *too* much damage, but I do think my
approach would be better for the project as a whole. I'm happy to put
that disagreement to the project and see how people vote.
> Additionally, my original proposal had the time extension start from the
> point where it was proposed, rather than from the end of the current
> discussion period. The reason for this was to encourage that extensions
> are only proposed and seconded when they would actually be needed,
> rather than proactively by people who actually care only about avoiding
> the vote at all, but I think we can also avoid that issue by mandating
> that a time extension can only be proposed if there are less than 48
> hours left in the discussion time currently.
I'm still not a huge fan of starting the time extension from the point
when it was proposed because I think it adds a fair bit of unnecessary
complexity to figuring out exactly when the discussion period ends. If
everything is based on the original proposal, the Project Secretary can
state the official timing of the original proposal and then all other
deadlines are easily derived from that. I'm leery of creating a situation
where we have to have an argument about email Date headers versus Received
headers or something else similarly tedious. (Some of this applies for
any deadline, I realize, but I think this might make it worse.)
> - Once the discussion time has reached 4 weeks, further extension
> proposals can be objected to by any developer. If the number of
> opposing developers is higher than the number of valid seconders for the
> extension proposal by the time the discussion period would run out if
> the time extension had not been voted upon, then the time extension
> does not happen.
This is an interesting way of handling voting on extensions. I'm not sure
what to think of it; voting on the mailing list feels like it may be
chaotic, and I'm not sure the Project Secretary is going to enjoy the
counting process, but it does have the merit of not introducing a new
system.
> On another note,
> I note that Russ's proposal does not change §5.1.5 (Project Leader -
> Powers - "Propose draft General Resolutions and amendments."). Since we
> now will start referring in appendix A to draft options as "proposals"
> and those who propose them as "proposers", it may be best, in the
> interest of confusion, to also change §5.1.5 to be more explicit about
> the fact that proposals from the DPL do not require any seconds.
Thank you, good catch. I have now added:
Section 5.1.5
-------------
Replace in its entirety with:
Propose General Resolutions and ballot options for General
Resolutions. When proposed by the Project Leader, sponsors for the
General Resolution or ballot option are not required; see §4.2.1.
to my draft.
There were also two other places (in 4.2.5 and 6.3.3) where "amendments"
needed to be changed to "ballot options." I've added those to my draft GR
as well.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: