Revised RFC 1 - Need Comments

Steve Lime Steve.Lime at DNR.STATE.MN.US
Wed Oct 11 13:48:07 EDT 2006


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/



More information about the mapserver-dev mailing list