Re: GRs, irrelevant amendments, and insincere voting

["Marcelo E. Magallon" <mmagallo@debian.org>]

 > I beg to differ.  After catching up on the list I see that a couple
 > of people claim to have ranked option C below further discussion.
 > 
 > Option C was proposed as "AMENDMENT BR3" to this mailing list[1].
 > 
 > There *was* no discussion of it, really.  It collected its seconds,
 > and there was a side discussion between Manoj Srivastava, Richard
 > Braakman, and some other folks about whether the DFSG and Social
 > Contract were separate documents or not (which was no more a failing
 > of amendment BR3 than it was of BR2, the amended form of Manoj's
 > proposal which ended up on the ballot as Option A).

 Ok, here's my vote:

 | - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 | [ 2 ] Choice 1: Proposal A [3:1 majority needed]
 | [ 1 ] Choice 2: Proposal B [3:1 majority needed]
 | [ 4 ] Choice 3: Proposal C [3:1 majority needed]
 | [ 3 ] Choice 4: Further Discussion
 | - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

 Why is that?

 Proposal B doesn't create foundation documents.  It just defines a
 certain kind of documents that the developers as a body can issue and
 modify.  In particular, it doesn't embed a list of documents with
 special status into the constitution itself.  If for whatever reason a
 new document pops up which is to be considered a foundation document, a
 vote has to be held to modify the constitution.  The vote will end up
 being something like "ratify Document Foo and amend the constitution to
 include it in the list of foundation documents".  If Document Foo is
 not regarded as a foundation document it's not "critical to the
 Project's mission".  I don't know which kind of document this would be.
 Certainly not something as the policy, since holding a vote to ratify
 something that would be laughable and counterproductive.  So what's the
 point of having foundation documents?  Proposal B is the least
 intrusive change and keeps close to the original formulation, which IMO
 already said what Proposal B stated.

 Proposal A defines foundation documents, creates its list and includes
 the SC and the DFSG as foundation documents.  If people really want the
 extra bureaucracy, that's fine with me.  I'm really more interested in
 the ability to modify the SC.

 Proposal C does the same thing, but doesn't include the DFSG in this
 list.  If it really comes to choosing between 3:1 or not, I want
 equity.  If the SC requires 3:1, I want the DFSG to require the same.

 Why 2143 instead of 2134?  Because I prefer having further discussion
 on Proposal C rather than accept it as it is (where further discussion
 means "convince me it's a good idea, I don't think it is").  Should the
 project had gone bonkers and a majority of voters had ranked C over A
 and B I didn't want to contribute to a 3:1 majority for that option.  I
 wasn't sure if under the constitution that made a difference, I didn't
 had the chance to check (for whatever reason apt-cache search
 constitution didn't result anything at the time) and I had delayed my
 vote too much already (because of having my GPG key stored elsewhere).
 I just played it safe from my POV.

 > Can people *really* prefer "further" discussion when they do not
 > avail themselves of any discussion in the first place?  Think about
 > the literal meaning of ranking the preferences that way.  "I'd rather
 > see further discussion of this subject than see Proposal Q
 > implemented."

 Yes, that's what it means.

 > That doesn't leave people a way to say "hell no, I oppose Proposal Q,
 > and, for that matter, no amount of further discussion will persuade
 > me, so I'd rather not see that either".  In such a case, the right
 > thing to do under the Condorcet Method as I understand it is to leave
 > both "Proposal Q" and "further discussion" unranked.

 If there was a choice of "hell, no" I would have ranked it over C,
 that's right, but:

 > But strategic voters won't do that, because they can disadvantage an
 > actively disliked option more by ranking it below "the default
 > option", which is a Debian innovation.

 That's right, too.

 > These extra data reinforce my suspicion that the Condorcet Method is
 > best understood as understood as a technique for selecting among
 > candidates for office.  As a legislative technique, it may be a poor
 > fit, at least as we currently implement it, for the problem space.

 Might be.  I don't have a problem with that.  I have a problem with
 miscounted ballots, as it happened a few DPL elections ago, but since
 that didn't change the outcome, I was fine with that, too.  And ballots
 are being counted as documented now, so I'm ok with that.

 > There may be ways to rectify the problems I perceive by modifying the
 > SRP itself, in conjunction with eliminating the default option, but my
 > thoughts in this area are not well-developed yet.  Two factors I am
 > trying to keep in mind are: 1) limitations on the amount of labor the
 > Project Secretary can be expected to undertake just to run a vote;
 > 2) the possibility of simply shifting "insincerity" elsewhere in the SRP
 > rather than eliminating it.

 I'll be interested in seeing how you get rid of strategic voters, since
 from my POV that's a property of the method, not a deficiency.

 Marcelo