MapServer Technical Steering Committee Proposal
Thomas E Burk
teb at MALLIT.FR.UMN.EDU
Wed Jun 29 10:30:43 EDT 2005
>X-Umn-Remote-Mta: [N] lsv-m.tc.umn.edu [160.94.23.1] #+HF+LO+NM
>X-Umn-Remote-Mta: [N] mail.state.mn.us [156.99.125.109]
#+NE+NR+HV+UF+CP+CU (P,-)
>X-Umn-Report-As-Spam:
<http://umn.edu/mc/s?DK4vqOBfe5vlhfSWoxMIhO6P9rzZ3fOs23PZR9Wih4zQ
niiFmbC0b5UNtAnmnzwp6IRR3u1U9NLa at TKgzm761ACCgUAGqGadR>
>Mime-Version: 1.0
>Content-Disposition: inline
>Date: Wed, 29 Jun 2005 00:05:19 -0500
>From: Steve Lime <steve.lime at DNR.STATE.MN.US>
>Subject: Re: [UMN_MAPSERVER-DEV] MapServer Technical Steering
Committee Proposal
>X-To: fwarmerdam at gmail.com
>To: MAPSERVER-DEV at lists.umn.edu
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by
mallit.fr.umn.edu id j5T57idi019374
>
>Sorry to be so slow with comments. Had technical problems last
evening and MN is facing a State Govt. shutdown and preparing for
that is dominating normal work hours. Could have lot's of time to
work on this stuff come Friday... ;-)
>
>Anywho, like everyone else said, thanks to Frank for getting the
ball rolling. I think this is a solid document. I'd be happy to
chair this committee.
>
>I think using the mailing list is the right place to present a
proposal and vote. Once that has taken place I'd like to see a
"technical committee" portion of the website used to store
proposals as opposed to CVS or bugzilla. Voting history could be
appended once completed. And once a proposal has been accepted
then a bug filed to track it's implementation. CVS doesn't feel
like the right place for the proposals to me. Just an opinion,
perhaps there is precedence for using CVS. The website could then
be the place were committee make up, announcements and other
stuff could be presented to users.
>
>It would be nice to have a proposal template. Anyone seen
anything like that? I'd volunteer to work something up if there's
not already something out there.
>
>The suggestion of adding a "power user" is a good one too- Perry
fits that description although I believe Frank included him as
the UMN connection. That's not absolutely necessary in my
opinion.
>
I'd like to see Perry kept on the proposed committee list.
Tom
>Steve
>
>>>> Frank Warmerdam <fwarmerdam at GMAIL.COM> 06/24/05 4:16 PM >>>
>Folks,
>
>We have had lots of talk over the last year or more about
"process"
>but without a process to make a decision we haven't really done
anything.
>I have prepared a proposal for a mechanism, which is attached
and
>also available in CVS under rfc/ms-rfc-1.txt.
>
>I am first putting this up for discussion but assuming
relatively positive
>feedback I will seek unanimous approval by the proposed voting
members:
>
> Steve Lime, Daniel Morissette, Frank Warmerdam, Sean Gilles,
Assefa
> Yewondwossen, Howard Butler and Perry Nacionales.
>
>This isn't meant to be the be-all and end-all of committee
constitutions.
>Just enough process to get us going so we could decide a few
other
>things and know we have reached some sort of closure.
>
>
>
> MS RFC 1: Technical Steering Committee Guidelines
> =================================================
>
>Author: Frank Warmerdam, Independent, warmerdam at pobox.com
>Proposed: 2005/06/24
>Last Edited: 2005/06/24
>
>Status: Proposed
>
>
>Summary
>=======
>
>This document describes how the MapServer Technical Steering
Committee
>determines membership, and makes decisions on MapServer
technical issues.
>
>In brief the technical team (primarily developers with commit
priviledges)
>votes on proposals on mapserver-dev. Proposals are available
for review
>for at least two days, and a single veto is sufficient delay
progress though
>ultimately a majority of members can pass a proposal.
>
>
>Detailed Process
>================
>
> 1) Proposals are written up and submitted on the mapserver-dev
mailing
> list for discussion and voting.
>
> 2) Proposals need to be available for review for at least two
business
> days before a final decision can be made.
>
> 3) Detailed proposals, especially those that are likely to live
> for a long time, should be written up in flat text, and
submitted in
> mapserver/rfc (in CVS).
>
> 4) Respondents may vote "+1" to indicate support for the
proposal and a
> willingness to support implementation.
>
> 5) Respondents may vote "-1" to veto a proposal, but must
provide clear
> reasoning and alternate approaches to resolving the problem
within the two
> days.
>
> 6) Anyone may comment on proposals on the list, but only
members of the
> Technical Steering Committee's votes will be counted.
>
> 7) A proposal will be accepted if it receives +2 (including the
proposer)
> and no vetos (-1).
>
> 8) If a proposal is vetoed, but an absolute majority of
committee members
> support the proposal (with +1's) then it passes.
>
> 9) Upon completion of discussion and voting the proposer should
announce
> whether they are proceeding (proposal accepted) or are
withdrawing their
> proposal (vetod).
>
>10) The Chair gets a vote.
>
>11) The Chair is responsible for keeping track of who is a
member of
> the Technical Steering Committee (perhaps as part of a TSC
file in CVS).
>
>12) Addition and removal of members from the committee, as well
as selection
> of a Chair should be handled as a proposal to the committee.
>
>13) The Chair adjudicates in cases of disputes about voting.
>
>
>When is Vote Required?
>======================
>
> o Anything that could cause backward compatability issues.
> o Adding substantial amounts of new code.
> o Changing inter-subssytem APIs, or objects.
> o Issues of procedure.
> o When releases should take place.
> o Anything that might be controversial.
>
>
>Boundaries of "Technical"
>=========================
>
> o If it relates to changes in the code, it is technical.
> o If it relates to how the developers cooperate, it is
technical.
> o If it relates to documentation, or web site it is arguable
whether
> it should be decided by the technical steering committee.
> o If it relates to events such as conferences, it is not
technical.
>
>
>Observations
>============
>
> o The Chair is the ultimate adjudicator if things break down.
>
> o The absolute majority rule can be used to override an
obstructionist
> veto, but it is intended that in normal circumstances vetoers
need to be
> convinced to withdraw their veto. We are trying to reach
consensus.
>
> o It is anticipated that seperate "committees" will exist to
manage
> conferences, and possible documentation and web sites.
>
>
>Bootstrapping
>=============
>
>Steve Lime is declared initial Chair of the Technical Steering
Committee.
>
>Steve Lime, Daniel Morissette, Frank Warmerdam, Sean Gilles,
Assefa
>Yewondwossen, Howard Butler and Perry Nacionales are declared to
be the
>founding Technical Steering Committee.
>
>
>Best regards,
>--
>---------------------------------------+------------------------
--------------
>I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam at pobox.com
>light and sound - activate the windows |
http://pobox.com/~warmerdam
>and watch the world go round - Rush | Geospatial Programmer
for Rent
>
>
More information about the mapserver-dev
mailing list