[Incubator] Speak up if you think the draft "Project Graduation Checklist" has any remaining issues

[Daniel Morissette]

On 12-03-03 4:27 PM, Cameron Shorter wrote:
> I've updated the draft "Project Graduation Checklist", in line with
> comments from the last incom meeting.
> If anyone has any outstanding comments on this document, can you please
> say so.
> I'd like to see it approved at the next Incom meeting.
>
> Latest draft here:
> http://wiki.osgeo.org/index.php?title=Draft_Project_Graduation_Checklist_Draft&oldid=61029
>

Hi Everyone,

One very important item to me which was not emphasized enough in the 
previous version is essentially gone in the new version. While I would 
agree that it is a kind of subjective item, it is still one of the key 
requirements to measure and test the long term viability of a FOSS 
project. I used to state it in my own words as:

"Project has demonstrated that it has an open and active/healthy users 
and developers community."

Several things are implied by this statement:

- OPEN: open license, open communication channels (lists, IRC, etc.), 
open to new members joining (PSC, committers, contributors), open and 
documented decision process, with decisions happening in the open, 
taking into account community input, and not behind closed doors and 
just reported to a public list. We have blocked projects in the past 
because they were not open enough and forced them to demonstrate that 
they could operate in a more open way for several months before they 
could graduate.

- ACTIVE/HEALTHY: An active and healthy community of users AND 
developers working hand in hand is a measure of the success and interest 
driven by a FOSS project and should be a good indication of its 
potential long term viability. This should be a requirement for 
graduation from the incubator. The presence or lack of an active/healthy 
users and devs community is usually apparent in a review of the 
project's mailing lists and other communication channels. We have turned 
down projects in the past with a small bus number or which were lacking 
an active community.


Actually, I do not find the word "open" a single time in the new 
document which is a bit scary for a FOSS checklist. And it may even be 
possible for one to pass the complete checklist with a project with a 
closed source license and closed management processes that simply 
reports their progress and decisions on a public list (without 
necessarily making decisions in the open).


I would propose the following modifications:

1- Under "Intellectual Property and License", add "All project source 
code, documentation and process documents are available under a license 
recognized by the Open Source Initiative (opensource.org)"

2- Under "Processes", item 3 could possibly be reworded as follows:

"""
3. The project has open and documented management processes. This is 
typically done within a Developers Guide or Project Management Plan.

     * The project has a suitable open governance policy ensuring 
decisions are made in the open, documented and adhered to. This 
typically means a Project Management Committee has been established with 
a process for adding new members. A robust and open Project Management 
Committee will typically draw upon developers, users and key 
stakeholders from multiple organisations as there will be a greater 
variety of technical visions and the project is more resilient to a 
sponsor leaving.
     * The project uses public communication channels for decision 
making to maintain transparency. E.g. archived email list(s), archived 
IRC channel(s), public issue tracker.
"""

3- Under "Community":

- To be honest I do not understand why committee requirements are 
grouped under a "Community" top-level section that falls outside the 
checklist section... is this intended or a mistake? Shouldn't this 
section be called "other committee requirements" or something like that? 
And also let's make it clear whether those requirements from other 
committees are part of the graduation checklist or not (since this group 
falls outside the "= Checklist =" grouping it's not clear whether they 
are hard requirements or not).

- With respect to the "Community" sub-section itself, I'd be tempted to 
change that title to be a second-level like the others (i.e. == 
Community ==) and make it fit in the master checklist, and then add a 
checklist item "Project has demonstrated that it has an open and 
active/healthy users and developers community."

Sorry for the late feedback...

-- 
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000