Revised RFC 1 - Need Comments

[Howard Butler]

I am also uncomfortable with the TSC anointing itself as the PSC.  I 
propose that ratification of the new RFC 1 (or 20) and PSC come from 
the community via non-anonymous poll like we did for RFC 10 (Join 
OSGeo).  After ratification, the community nominates folks that it 
wants for the 2 open community seats and votes them in via the same process.

What about the concept of terms?  I think to have it truly represent 
the project, the community must have the ability at some point to 
swap out members of the PSC (not just having the PSC swap its own 
members in and out).  The RFC talks about inactivity, which is 
probably the most common reason why someone would be replaced.  I 
would propose that the term for all PSC seats be 2 years or 2 
releases, whichever is shorter.  Five technical seats and four 
community seats (as currently proposed).  To be eligible for a 
technical seat, you would have to be a CVS committer.  No special 
qualifications for a community seat.  After your term is up, the 
community yay or nays you for another term.  We would need more 
details of how this might actually work.  Is this a bad idea?

A big take home message of FOSS4G for me this year was Jim 
Westervelt's keynote where he talked about GRASS and continuous and 
somewhat predictable releases.  GRASS sort of withered away as 
releases dried up (to be resurrected later by the current GRASS crew) 
.  It's my opinion that the PSC's #1 job is to make sure releases 
happen in a timely and regular manner.  Without releases open source 
projects die.  I would add that thanks to Daniel, 4.10 was the 
tightest and best-organized MapServer release I've been a part of so 
far.  Thanks Daniel!

Calling this RFC 20 or RFC 1 makes no difference to me.  Either way, 
the original RFC 1 needs to stick around in some form and link to the 
current constitution ;)

I would add that I'm a bit hesitant to start creating lots of 
subcommittees to do this and that task.  My experience with OSGeo is 
this can generate a lot of communication overhead, especially if you 
have to start following all of them to have a picture of what 
developments are happening and where things are going.  They also 
tend to add meeting time pressure, and they can disrupt serendipitous 
and adhoc contribution.  What are other folks' opinions here?

Howard

At 12:48 PM 10/11/2006, Steve Lime wrote:
>1. I'm all in favor of transparency, in what responsibilities are and
>who is making
>decisions. Trouble is coming up with the laundry list of proposed areas
>the PSC
>has authority. Perhaps that's a good point of discussion.
>
>2. I was thinking sub-committees when I altered that portion of the
>document.
>
>3. RFC numbering? I asked about that way back when I started to edit
>this.
>There were some comments about this RFC replacing number 1 as opposed
>to
>sitting alongside it. The 1a  designation was simply a quick choice on
>my part.
>I'd be perfectly happy calling this RFC 20 since I think the original
>RFC 1 needs
>to be available long term as originally written.
>
>One thing I'm uncomfortable with is the TSC annointing itself as the
>PSC. But then
>again I don't know how that should happen. Perhaps the TSC as it sits
>with 2 or 4
>open memberships (with a community-based nomination, or even voting
>process)
>is a good compromise.
>
>Steve
>
> >>> Daniel Morissette <dmorissette at MAPGEARS.COM> 10/11/2006 11:26:27 AM
> >>>
>Steve Lime wrote:
> >
> >   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1a
> >
> > Feel free to edit, pass along comments, concerns or whatever...
> >
>
>A few comments:
>
>1- Area of authority/responsibilities:
>
>I think the area of responsibilities of the PSC should be defined. All
>
>that I find in the current document is "... makes decisions on
>MapServer
>project issues - both technical and non-technical." I guess this
>implies
>that the PSC mandate is to make decisions on any question that relates
>
>to MapServer, but that's only implied and not made explicitly clear. If
>
>we want the PSC to be the ultimate decision making authority for
>anything that relates to MapServer then should we not state that
>clearly
>in this document? I'm just trying to avoid repeating what happened
>during the "should MapServer join OSGeo?" discussions when we realized
>
>that there was nobody with clear authority to make that decision.
>OTOH, if someone thinks that the PSC should not be the ultimate
>authority with respect to MapServer then we should define what the
>limits of its authority are and who else is responsible for questions
>outside of those limits.
>
>
>2- Subcommittees or parallel committees?
>
>RFC-1a says: "It is anticipated that seperate "committees" will exist
>to
>manage conferences, documentation and web sites.  That said, it is
>expected that the PSC will be the entity largely responsible for
>creating any such committees."
>
>Would conference, docs, website and other committees be sub-committees
>
>or parallel committees? My first idea is to think that they should be
>sub-committees who report to the PSC, a bit like OSGeo committees
>report
>to the OSGeo board via their chairs. However if others think
>differently
>I'm open to discussion, but either way I think the relationship needs
>to
>be made clear here.
>
>3- RFC numbering:
>
>I find that reusing RFC numbers for revised documents can lead to
>confusion. I think RFCs should be set in stone after they have been
>adopted. In this case calling the revised version RFC-1a isn't that
>bad,
>but would it not be more clear if this new doc was called RFC-20 with a
>
>note in RFC-1 that it is obsolete and superceeded by RFC-20 (and a note
>
>in RFC-20 that it is obsoletes RFC-1)?
>
>This way RFC-1 remains available for reference by people reading old
>mail archives or reading old documents that were built against RFC-1,
>and RFC-20 becomes the new reference for new discussions.
>
>I guess calling this revised doc RFC-1a makes some sense since it is
>the
>root of the committee and we want that to be RFC-1-something, but for
>any other RFCs I think using new numbers and obsoleting old RFCs would
>
>make more sense. Using new RFC numbers would also allow for a single
>RFC
>to obsolete several old RFCs at once, which would be impossible if our
>
>approach is to call revised docs RFC-11a, RFC-11b, etc.
>
>
>My 0.02$... I'd like to hear what others think on those topics.
>
>Daniel
>--
>Daniel Morissette
>http://www.mapgears.com/