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