[GRASS-PSC] Re: GRASS PSC

Brad Douglas rez at touchofmadness.com
Thu Oct 26 17:48:08 EDT 2006


On Thu, 2006-10-26 at 13:51 -0400, Helena Mitasova wrote:
> Dylan Beaudette wrote:
> > On Thursday 26 October 2006 06:44, Scott Mitchell wrote:
> >   
> >> On 26 Oct 2006, at 08:37, Maciej Sieczka wrote:
> >>     
> >>> Markus Neteler wrote:
> >>>       
> >>>> I have updated at least
> >>>> http://grass.gdf-hannover.de/wiki/
> >>>> GRASS_Project_Steering_Commitee#Status_September_2006
> >>>>
> >>>> The RFC-1 was discussed very controversal, opinions were orthogonal.
> >>>> Let's see if we can fix this. I cc to all PSC members.
> >>>>         
> >>> I, for one, don't have problems with it.
> >>>
> >>> technical note: there are 3 links to RFC-1 on the GRASS WIKI page;
> >>> only the 3rd one links to actuall document, the 2 other link to
> >>> http://www.ietf.org/rfc/rfc1.txt; ???
> >>>       
> >> Yes, weird - the others don't show up if I click on the edit tag,
> >> either - a bug?
> >>
> >>     
> >>>> @GRASS-PSC: should I create a dedicated mailing list to get
> >>>> communication
> >>>> archived?
> >>>>         
> >>> +1

We should have a PSC mailing list to discuss future tasks.  Individual
proposals/changes (read: small scale) will most likely be hashed out in
the devel list.

There are many projects that exist within the GRASS umbrella.  They
could probably benefit from some coordination.

> >> +1 - I imagine that much discussion will occur in the bigger lists,
> >> but also that part of the idea of delegation is that we're expected
> >> to sort some things out ourselves.  Having an archive keeps the
> >> discussions documented and open.
> >>
> >> I've looked back over many of the old discussions, and the RFC-1.  I
> >> perceived some concern in the mailing list posts about the nature of
> >> the hierarchy outlined in the RFC, and I know we've wondered about
> >> the role of "influential" contributors that have chosen not to be in
> >> the PSC.  I've experimented with wording to try to hopefully
> >> alleviate some of these concerns.  I am not completely happy with the
> >> wording thus far, so have not committed the wording back into CVS,
> >> but copy the relevant section here, along with a diff.
> >>     
> 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.

+1

> >> 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.

Agreed.  There's been cases where I've said to myself, "What the heck
was I thinking?" when I knew better.

> > +1 on the 4-5 business days. As many of us are in different time zones, and 
> > often in the field- this would be a nice window for voting.

+1.  Simply getting through the volume of emails can take a day or more
at times.  Lately, I've had to delete entire threads on topics not
directly related to me in order to keep up.

Would it be beneficial to have each member of the PSC to keep watch over
a selected topic on the devel list (vector/raster/imagery/GUI, etc.)?  I
think it would greatly reduce individual burden and ensure nothing gets
"lost".


-- 
Brad Douglas <rez touchofmadness com>                    KB8UYR/6
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785




More information about the grass-psc mailing list