[RFC] tweak to voting rules

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Wilbur wrote:
> On Wed, 2006-11-29 at 21:33 -0500, Aaron Bentley wrote:
>> I think we need to differentiate between two reasons for voting against
>> a patch:
>> 1. This implementation needs work before we can accept it.
>> 2. This patch is a bad idea, and we should never accept it, even if
>> well-implemented.
>>
>> So I propose we change things slightly:
>> - -1 : patch needs work
>> - -2 : patch is a bad idea
> Since -(-x) == +x, I recommend:
> -1 : patch needs work
> -2 : patch is a bad idea

That was an artifact of Enigmail.

>> That will allow BB to categorize the -1 patches differently from the -2
>> patches, and still get the patches off the pending list, where they
>> really don't belong.
>>
>> I suppose while we were at it, we could also change the positive end of
>> the scale:
>> +1 : submittable, if you make certain changes
>> +2 : submittable

> Seems you are simply recasting the previous voting scheme as integers
> instead of real limits: -1, -0, +0, +1.  This is a good idea as it makes
> distinguishing them as integer fields in a web application possible.

Actually, the full range would be
- -2 bad idea
- -1 patch needs work
- -0 somewhat uncomfortable
+0 okay with me
+1 I want this merged, with certain changes
+2 I want this merged, no changes required.

Right now, we're often using +0 to mean "patch needs work" because we
want to be nice, though technically right now we should be using -1
(because the current patch isn't suitable -- -1 doesn't say *why* it's
not suitable).

> Should the management go from "auto" to "manual" if a patch gets a -2
> and a +1, etc?

Well, no matter what, a patch can always be marked "merged" when it is.

I'm not too worried about the edge cases-- I just want the other 95% to
be as smooth as we can make it.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbuBi0F+nu1YWqI0RAo/yAJ9e9FoJT6VQkCpew77Z4T0gKQzL9wCgiXRY
3EukIqqQ31mjnm7e2cs6Y2M=
=Hjfl
-----END PGP SIGNATURE-----