[Incubator] Meeting Reminder

[Frank Warmerdam]

Cameron Shorter wrote:
> Sorry Frank,
> Now that daylight saving has switched, this timeslot is 04:00 in Sydney.
> In the meeting, could you please see if this timeslot works for 
> participants:
> http://timeanddate.com/worldclock/fixedtime.html?year=2006&month=4&day=9&hour=10&min=0&sec=0 
> 
> Sydney: 9pm
> Berlin: 1pm
> New York: 7am
> Vancouver: 4am
> http://timeanddate.com/worldclock/meetingtime.html?day=9&month=4&year=2006&p1=240&p2=179&p3=37&p4=256 
> 
> (I'm not sure if there are any participants from Vancouver).

Cameron,

There are two west coast members, Daniel Brookshier and Rich Steele.  Also
one member (Sean Gilles) on either Central or Mountain time (I'm not sure
which).  I have added your suggestion to the agenda.  Of course without
you there it may not find many supporters!

> Comments on agenda:
> * There seems to be a lot of work for a Project Mentor if that mentor is 
> not already involved in the project.  I suspect that OSGeo will have 
> problems finding enough mentor volunteers.  Consequently, I think that 
> the biggest obstacle a project will face in joining OSGeo will be to 
> find themselves a mentor.  So I suggest one of three things:
> 
> 1. The mentor's role becomes more of an auditor.  Ie, to verify the 
> project has completed OSGeo's criteria.  The onus is on the project 
> participants to get the project in order.

I am generally in agreement with this, but I would like to see the
mentor providing an "insider" advisor role which hopefully wouldn't
be too onerous.  However, my suggestion that the mentor join the mailing
lists and so forth in order to audit the project status is a pretty heavy
load of work.

> 2. The mentor's role is sponsored.

While this is possible, as a board member, I'm going to be pretty
hesitant to spend foundation money on mentors for a project unless
I'm really hungry to get that project into the foundation.

> 3. The mentor can also be a project member.

My problem with this is I feel it would be hard for the mentor to
be objective about the project.  I think it would also be hard in
some new projects to find a project member who is also knowledgable
about the foundation, it's incubation standards and so forth.

However, I quite agree with your point that it will be hard to find
people prepared to take on the work load of an incubation mentor.
Too some extent, I see this as a gating limit that will keep the
number of projects in incubation from growing too large, and in that
sense I think it is good - keeping things managable.

An early document I wrote up on incubation suggested that the
incubation committee ought to be who does the initial review of
submissions to join the foundation, and that the incubator should
not forward a project recommendation for incubation on to the board
unless someone on the incubator is willing to be mentor.

I think this would help weed out projects that we wouldn't mind
having in the foundation but for which no one is really very
enthusiastic.

I personally feel we need to grow the number of projects within
the foundation at a fairly modest rate (perhaps 4-6 new major
projects per year for instance) so we can maintain a reasonable
degree of oversight, quality assurance (in a general sense) and
promotion for foundation projects.

Having said that, I also think we may find we want to have a kind
of "junior project" that is essentially under the sponsorship of
another project.  So, perhaps, libgeotiff might join the foundation
but as a subproject of GDAL.  I have yet to pursue this path of
reasoning very far.

> * Regarding Project Infrastructure Migration:
> I still feel that the cost of Migration in and out of Colabnet is larger 
> than any benefits it may bring.  I'm particularly concerned about the 
> loss of history in bug trackers and email lists.
> Daniel has said that "I won't say that we are best in breed in all the 
> components (except svn), but we are best in breed as an integrated 
> multi-host platform."
> For me, I don't want to move from my "best of breed" tools to a lesser 
> tool.  Little things like not having a theaded email archieve are 
> annoying if you know you used to have it.
> So for Mapbuilder, I'm advising our PSC not to migrate to Collabnet yet.

No problem as far as I am concerned.   As time passes we may need to
wrestle further with whether a greater degree of commonality in our
project tools (bugs, mailing lists, etc) is desirable and how to approach
it.  But my position is that the infrastucture is there if you want it,
but we aren't forcing it down anyones throat.   For GDAL I will try and
fit into some parts (website, downloads) while ignoring parts with
too high a transition cost for my liking (bug tracker, mailing lists).

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    | President OSGF, http://osgeo.org