[GRASS-PSC] RFC3: New voting rules

[Hamish]

Hi all,

sorry for my long absence, I've hardly been on email at all for many
weeks now. (and enjoying the break from distractions! :) I certainly
haven't caught up with all the messages in my inbox, there's a good
chance I've missed things.

But since people want to get moving, here are my comments on the text of
RFC3 as it appears on the trac wiki today. (I guess that makes it
version 10 according to trac)


In general it just codifies what we're already doing, so no big
surprises. Devil is in the details, and we are detail oriented
people, so let's get this right. :)


Proposals (2): make it clear that the Chair is the to to decide that "no
more progress is being made", and close the vote in that case. The last
sentence of (2) seems to indicate that, but the wording is a bit muddy.

Voting (3): Strike the invalid veto text. I will not support passing
RFC3 with that in place. Who is to judge that the reasons given are
clear? What if we know something is definitely not the right solution
but don't know the correct answer? In yacht racing we used to have a
saying: "even if you do not know what the right thing to do is,
especially then, never knowingly do the wrong thing."
If nothing else it is IMHO quite disrespectful to our fellow PSCers.

Voting (4): "... but has no effect" -- "other than to formally indicate
the voter's position." (which should hold community weight even if it
doesn't count in the calculus of the vote, so should be given a nod
in the text)

[new] Voting (9): The Chair is responsible for validating the final
result. (or some text like that, we don't seem to explicitly say it
elsewhere)



some other points to consider:

- lesser threshold for granting commit rights? (100% PSC members
answering not req'd, just a quorum of 51% and no vetos. moreover
maybe a shorter timeout of 3-4 days for these. Voting (8) mentions
"active voters" but AFAICT elsewhere we don't formally discuss
absentees vs. abstainers)


- passing rfc by simple majority, or require a higher threshold?
- overriding a veto by simple majority, or require a higher threshold?

in both the above cases it seems to me the healthiness of the overall
project would benefit by forcing us to work very very hard to come to a
real consensus rather than expedite a quick decision. FOSS runs on good
interpersonal relationships; any chance of unresolved bad feelings being
left in the wake of a decision can be quite toxic to the long term heath
of the project and avoided at all costs.


As I catch up on my email I'll reply to the RFC3 threads on the PSC
list inline, probably there are many fine points made by others
already that I missed. :)


regards,
Hamish


ps- I still strongly believe that a wiki is not the place to house
approved RFCs, it should be in a more formal and secure VCS, such as
Subversion. It is not necessary to keep it in the source code tarball,
but that does have the benefit of widely disseminating copies. For
historical changelog + diff interest, developing the RFC text in the
final VCS would be preferable. (culturally, commit log messages tend to
be much better in SVN than in a wiki, and the "why" of a change is quite
important in this context. also the wiki is open to anyone on the
internet who cares to create an account. will our RFCs get spammed or
vandalized? even if approved motions are converted to locked pages, that
doesn't work for working documents. these aren't some simple help page.)