Hamish,
you make many good points, but to follow proper procedures, the text cannot
be changed after other members of PSC already voted for it. Just to recall
the timeline of this RFC3:
July 31 call for comments
Aug 25 motion called and seconded
Sep 20 all votes received except one
So if we want to modify the text we need to close this vote (which Markus
should do today), then open a new discussion about the voting rules
modification and call a new vote so that all PSC members can vote about the
new text.
Your points are really important and after a discussion they have a
potential to improve the voting process so I suggest that we follow the
procedure outlined above - finish the vote on the current RFC3 and then you
should start a discussion on modifications - the below comments are a good
start.
I hope this is acceptable to everyone,
Helena
On Sun, Oct 5, 2014 at 10:29 PM, Hamish hamish.webm...@gmail.com wrote:
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.)
___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc
--
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://www4.ncsu.edu/~hmitaso/
http://geospatial.ncsu.edu/
email: hmit...@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
___
grass-psc mailing list
grass-psc@lists.osgeo.org
