[GRASS-PSC] Re: GRASS PSC

[Paul Kelly]

Hello everyone

On Thu, 26 Oct 2006, Helena Mitasova wrote:

> In the section 2 regarding the developers who are not memebers of PSC, I 
> suggest to replace
>
> "their input is encouraged and valued"
>
> with
>
> " PSC will seek and rely on their expertise and advice when making decisions 
> in the relevant areas."
>
> I for myself don't feel confident to make decisions in areas where I don't 
> have sufficient expertise
> (and those are many) and I would have to rely on advice from people like 
> Glynn.
>>> I also wonder about a longer voting period - I recognize the
>>> advantage of keeping it short, but two days still seems very short to
>>> me.  Maybe a week, the other suggestion in the archives, IS too
>>> long?  Maybe a compromise of 4-5 business days?
>>> 
> We need definitely more time for voting - you actually have to THINK
> before casting the vote (I have sometimes voted hastily right away
> and then realized that was not what I wanted). The time should depend on
> a complexity of the issue - for example you would need to study and 
> understand
> a proposal for new raster format for a few weeks before voting on it.
> You may also seek some advice from others or discuss it with colleagues.
> Once you cast your vote and the decision is made you cannot take it back.
> So I agree with 1-2 weeks on small issues with extended period
> for more complex projects.

OK I think Helena's proposed changes sound good, BUT:- I wonder if hacking 
at this first RFC for PSC operation is really the best way to go. I feel 
the issues I brought up in my last e-mail about this:
http://grass.itc.it/pipermail/grass5/2006-August/024700.html
haven't really been addressed by any of the changes. My concern is (as 
before) about limiting the amount of things we (i.e. the PSC) have to vote 
on, because most of us only have expertise in a limited range of areas and 
simply can't make meaningful decisions on most technical issues. Speaking 
for myself, there's only a very limited range of technical areas on which 
I'd feel comfortable prononuncing an opinion strong enough to be counted 
as a vote.

But the RFC says the PSC can make "major decisions on technical issues and 
project management", and in general I feel the logic with the concentric 
circles is wrong because it simply doesn't apply to the way GRASS 
organisation is structured - as I said before it appears to assume that 
the "inner circle" PSC know a lot of technical details etc. but as I said 
there's loads of areas I wouldn't be capable of making a competent 
decision on (an example being the recent C version of r.out.gdal - how was 
I to see the major issue with it requiring the whole map to be held in 
memory?). Also in our case some of PSC aren't even developers (of course 
I'm not saying they shouldn't be there, just that our PSC appears to be 
structured differently from the PSC and project structure that the 
concentric circle model appears to have been designed for).

IMHO the PSC should fill the gap we currently have, i.e. project 
management, rather than replace everything. I don't think it's fair on 
Markus that he experiences most of the pressure for those types of 
decisions at present. I think it might be a good idea to make it clear 
that the PSC is only there to advise and if necessary make decisions on 
project management (i.e. policy decisions, political and promotional stuff 
and that kind of thing). And the final say on technical decisions should 
rest with consensus on the developers mailing list as it always has done. 
This part isn't broken and it doesn't need fixed.

Is it worth me trying to put that into a form of words and proposing it as 
a replacement? Or would it be too radical a change?

Does anyone know what OSgeo requires for a PSC's terms of reference? I 
mean, is there any way we could come up with an unacceptable RFC that 
could then be ruled "unconstitutional" for OSgeo membership or something 
like that?!!! :)

Also I guess the reason we're not having this discussion on the dev list 
is that it has been delegated to us to sort a solution to this so it's us 
who need to do it...

Paul