[Incubator] Project Status Template
Paul Spencer
pspencer at dmsolutions.ca
Wed Apr 5 20:29:22 EDT 2006
I am not a big fan of designing a process to fit the tools at hand
however. Just because it is difficult or impractical with the
current toolset shouldn't be a limiting factor.
One decision we need is to set the bar for project entry into
incubation. I don't think this can be done immediately but will grow
out of the current effort.
Second is to acknowledge that project that make it into incubation
will use the same infrastructure and mostly identical to official
projects. There may be another bar that indicates when a project has
reached sufficient maturity within the incubator to justify use of
osgeo resources, although I personally think this will end up being
almost the same as gaining entry to incubation so its probably not
worth it.
what else do we need to about this?
Paul
On 5-Apr-06, at 4:55 PM, Daniel Brookshier wrote:
> First on incubation and odds of success. Some open source projects
> have remained under a 1.0 release for years, only to get a burst of
> energy and create several quality releases. There are indeed also
> projects that have petered out before or after a release.
>
> The number one constant is the there are no constants. People have
> ever shifting priorities and available time to work on these
> projects. It is also damn hard to get a sustaining developer base
> to keep a project viable.
>
> The beauty of the Apache style incubator is that we help this
> process along. The forms, procedures, and monitoring of project
> status helps projects think about how to succeed.
>
> Allowing a project to start work in the incubator should only be
> about the process of doing the up front work like completing a
> project questionnaire and being assigned to a rep from the
> incubation committee. Success will then depend on the merits of the
> idea and the ability of the project owners to either create the
> code or rally others.
>
> More answers inline below
>
> Daniel Brookshier | Community Manager | CollabNet, Inc.
> 8000 Marina Blvd. Suite 600 | Brisbane, CA 94005 | USA
> O 972.422.5261 | C 214.207.6614 | dbrookshier at collab.net
>
>
> On Apr 5, 2006, at 11:16 AM, Paul Spencer wrote:
>
>> Frank, I don't have a strong opinion about this either way but I
>> think the committee/board needs to be able to justify the decision
>> one way or the other and I don't see a compelling argument (yet)
>> to believe that we should refuse project incubation on the basis
>> that they may not graduate.
>>
>> I do believe that incubator projects need to be presented
>> differently. The most expedient way to accomplish this would be
>> to have the project web site checked out under http://
>> incubator.osgeo.org/<projectname>. When a project is accepted,
>> the web site can be moved to http://<projectname>.osgeo.org/ with
>> very little effort.
>
> I would keep this to the wiki or project tracker if the form works
> well enough for us. Once a project is approved we can parent it in
> various ways to both projects and categories.
>
>>
>> It may also be relatively simple to have an SVN/CVS location for
>> incubator projects that is separate from official projects. I
>> can't imagine that it would be difficult to move an SVN tree when
>> a project becomes official.
>
> It is not difficult, but it is troublesome. That's why CollabNet is
> structured by project. It allows the project owner full control of
> their tools. If you do a sort of big svn with multiple projects
> there is a bunch of nastiness with read/write roles that you have
> to add. If you don't you will be trying to figure out why 20
> projects disappeared because of the new guy experimenting with
> deletes.
>
> Another problem is the way the tools are connected. For instance
> you can subscribe to the commits list to see svn commits, but there
> is no way to subscribe to just one branch. Thus another reason to
> be under a specific project as the first step.
>
> Finally is email lists in general. The tool does not let you move a
> list archive around. Even it it did, the addresses would need to be
> changed and there is no facility for that either. If the incubator
> project has its list from day one, no problem.
>
>>
>> It also should not be too difficult to offer an alternate download
>> site for incubator projects.
>
> Best to look at this by project again. We can create a page that
> might have this, but someone has to manage the page. The wiki is a
> good solution, but it may still be problematic. The tool does help
> by letting you look at a list by category. For instance:
>
> https://incubator-list.osgeo.org/
>
> or
>
> https://committee-projects.osgeo.org/
>
>
> To summarize, give a project its space as soon as it meets the
> minimum requirements. We can mange the system so that incubated
> projects are slightly out of the mainstream. We do want to be sure
> that they are visible enough to attract other developers and beta
> users.
>
> If a project does go completely dead, we can delete it or put it in
> a cemetery category. I just delete them if nothing happens in the
> svn for 6 months or so. I email the owner first and about 1 out of
> 5 email back that they have just made a commit of a beta release :o)
>
>>
>> DanielB, could you chime in with some comments on my assumptions -
>> anything I can do myself I assume is easy :)
>>
>> Sean, in joining late I seem to have missed how you and Frank
>> differ on incubation. Could you summarize your differences?
>>
>> Cheers
>>
>> Paul
>> On 5-Apr-06, at 10:27 AM, Frank Warmerdam wrote:
>>
>>> Paul Spencer wrote:
>>>> Frank ...
>>>> If there is a possibility that a project can be rejected then it
>>>> may be unwise to port the project's infrastructure into the
>>>> osgeo infrastructure since that may cause more work for the
>>>> project if they are rejected and migrate out.
>>>
>>> Paul,
>>>
>>> Well, if the approval is in doubt it would be prudent for a
>>> project to
>>> avoid the most expensive/disruptive types of migration.
>>>
>>>> Should we:
>>>> * make this possibility known and leave it to the project to decide
>>>
>>> This is the current approach.
>>>
>>>> * have the project pass an Incubator Committee vote on whether
>>>> its probability of success is high enough to warrant use of the
>>>> osgeo infrastructure (and how do we assess this)
>>>
>>> Well, I'm not too keen on this. *But* I don't think we should even
>>> be accepting projects into incubation unless we believe they are
>>> likely
>>> to pass incubation. I think this is one of the points that Sean has
>>> a different opinion that I do, I believe.
>>>
>>>> * have a parallel infrastructure for incubation projects, or
>>>> possibly just a parallel of a portion of the infrastructure such
>>>> as http://incubator.osgeo.org/<projectname>
>>>
>>> What would the benefit of this parallel infrastructure be? I'm not
>>> keen on any extra complication, nor for having to do further
>>> migration
>>> (other than updating a few status items) when transitioning from
>>> incubation to full membership.
>>>
>>> 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
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
>>> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>>>
>>
>> +-----------------------------------------------------------------+
>> |Paul Spencer pspencer at dmsolutions.ca |
>> +-----------------------------------------------------------------+
>> |Applications & Software Development |
>> |DM Solutions Group Inc http://www.dmsolutions.ca/|
>> +-----------------------------------------------------------------+
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
>> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Applications & Software Development |
|DM Solutions Group Inc http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+
More information about the Incubator
mailing list