Re: Why the gr_lenny ballot is the way it is
On Wed, Dec 17, 2008 at 4:15 PM, Manoj Srivastava <srivasta@debian.org> wrote:
> So, while the power set of the options is not feasible, we could
> have a slew of options combining the various proposed options, if
> people wanted to vote on a compatible set of options.
No. As I've said, people want to vote separately for separate
subjects, we don't want MORE options in this ballot. Please, no.
Nobody claims the issues aren't "related", but not everything that is
"related" deserves to be in the same ballot. There are three
questions that need answering, and these questions are independent.
You seem to be worried that having separate ballots would be "gaming"
the system, and would be prone to "strategic voting". That might be
true when the separate ballots actually hold competing candidates,
however in this case, each ballot would answer a different question,
so there's no such thing as voting for a less desired candidate in
order for your desired candidate to win... Yes, all these questions
are related to what will happen to Lenny, but that does not mean they
should all go into a messy ballot.
In this case, having separate ballots will more accurately reflect the
position of the project for the 3 issues at hand:
1) What do we do with licensing bugs in Lenny?
2) Does the RT have the power to decide what bugs to ignore?
3) Do we allow sourceless firmware in Debian?
These questions are related but separate, each person should be
entitled to vote on how they feel about each of them. There's no
"gaming" in this, just an accurate and simple way of finding out the
position of the project on 3 related-but-separate subjects. Condorcet
doesn't allow more than one "winner". And these option should all be
allowed to win (you even said that if neither 4 nor 6 win, they should
go on separate ballots in the future), thus, they should all go in
separate ballots _now_, it makes no sense to have them all in one
ballot where only one can be the winner.
I acknowledge that there would be some (extremely unlikely)
conflicting outcomes. However, if these unlikely outcomes were to
take place, we would have understand that that is actually the
position of the project and deal with that sensibly.
For example, let's say "Delay Lenny" won and "Allow sourceless
firmware" also won. Then, sourceless firmware that is otherwise
compatible with the DFSG would be allowed, and no longer an RC bug,
but the rest of the licensing issues (if any) would need to be
resolved.
Or, let's say "Delay Lenny" won and "Allow the RT to decide what to
ignore" also won. In this case, the RT would have to acknowledge that
the project prefers solving the issues to releasing, and thus
shouldn't ignore _those_ issues, but would be able to use the
ignore-<...> tags in the future with permission from the project.
The other outcomes that I foresee (the more probable outcomes) are not
so very conflicting and thus would not require much thought as to what
to do with them.
As I said yesterday, I hope you can take this into consideration, if
you decide to re-do the vote.
--
Love,
Marga
Reply to: