[Incubator] Steps toward merging/deprecating incubation documents

Cameron Shorter cameron.shorter at gmail.com
Sat Nov 29 16:49:40 PST 2014

Ok, proposed changes are now in place. Additions in style=red, deletions 
in <strike> font.
Hopefully style will by forwarded through the email list, otherwise 
follow the links to the wiki page.


  Project Graduation Checklist


The project has demonstrated that it has an open, active and healthy 
user and developer community:

 1. [open.1]Open: projects are expected to function in an open and
    public manner and include:
      * [open.1a]Open source license(s),
      * [open.1b]Open communication channels,
      * [open.1c]Open decision making process,
 2. [open.2]Active and healthy community:
      * [open.2a]The project should have a community of developers and
        users who actively collaborate and support each other in a
        healthy way.
        /Eg. collaboration on project activities such as testing,
        release and feature development./
      * [open.2b]Long term viability of the project is demonstrated by
        showing participation,supportand direction from multiple
        developers,power users, and/or sponsors, who come from multiple
        /Eg. The project is resilient enough to sustain loss of a
        developer or supporting organisation, often referred to as
        having a highbus factor <http://en.wikipedia.org/wiki/Bus_factor>./
      * [open.2c] Decisions are made openly instead of behind closed
        doors, which empowers all developers to take ownership of the
        project and facilitates spreading of knowledge between current
        and future team members.
      * [open.2d] Users are supported and encouraged, via an email list
        or similar.

    Copyright and License

We need to ensure that the project owns or otherwise has obtained the 
ability to release the project code by completing the following steps:

 1. [copyright.1]All project source code is available under an Open
    Source license.
 2. [copyright.2]Project documentation is available under an open
    license, such as Creative Commons.
 3. [copyright.3][copyright.1]The project code, documentation and data
    has been adequately vetted to assure it is all properly licensed,
    and a copyright notice included, as per aProvenance Review
 4. [copyright.4]The project maintains a list of all copyright holders
    identified in the Provenance Review Document.
 5. [copyright.5]All code contributors have agreed to abide by the
    project's license policy, and this agreement has been documented and


 1. [processes.1]The project has code under configuration management.
    /Eg, subversion, git./
 2. [processes.2]The project uses an issue tracker and keeps the status
    of the issue tracker up to date.
 3. [processes.3]The project has documentedand followsits management
    /This is typically done within a Developers Guide or Project
    Management Plan./
      * [processes.2a]The project has a suitable open governance policy
        ensuring decisions are made, documented and adhered to in a
        public manner.
        /This typically means a Project Management Committee has been
        established with a process for adding new members. A robust
        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./
      * [processes.2b]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./


 1. [documentation.1]The project has user documentation:
      * [documentation.1a]Including sufficient detail to guide a new
        user through performing the core functionality provided by the
 2. [documentation.2]The project has developer documentation:
      * [documentation.2a]Including checkout and build instructions.
      * [documentation.2b]Including commented code, ideally published
        for developer use.
        /Examples: javadocs for Java applications, or Sphinx
        documentation for Python applications./
      * [documentation.2c]Providing sufficient detail for an experience
        programmer to contribute patches or a new module in accordance
        with the project's programming conventions.
 3. [documentation.3] The project has deployment documentation:
      * [documentation.3a] Including, where appropriate, how to deploy,
        configure and optimise the application.

    Release Procedure

In order to maintain a consistent level of quality, the project should 
follow defined release and testing processes.

 1. [release.1]The project follows a defined release process:
      * [release.1a] Which supports both stable and development releases.
      * [release.1b]Which includes execution of the testing process
        before releasing a stable release.
 2. [release.2]The project follows a documented testing process.
      * [release.2a]/Ideally, this includes both automated and manual
      * [release.2b]/Ideally this includes documented conformance to set
        quality goals, such as reporting Percentage Code Coverage of
        Unit Tests./
 3. [release.3]Release and testing processes provide sufficient detail
    for an experienced programmer to follow.
 4. [release.4] The project has released stable, feature complete releases.
      * /Ideally this is demonstrated by describing risk adverse
        organisations who have deployed releases into production systems./

  OSGeo Committees and Community

The OSGeo Foundation is made up of a number of committees, projects and 
local chapters. This section gathers up information these groups have 
requested from OSGeo projects. These expectations are not mandatory 
requirements before graduation, but a project should be prepared to 
address them in order to be considered a good OSGeo citizen.


The OSGeoBoard <http://wiki.osgeo.org/wiki/Board>holds ultimate 
responsibility for all OSGeo activities. The Board requests:

 1. [board.1]A project provide a Project Officer as a contract point:
      * The Project Officer should be listed at:Project Officer
      * This person is established when the incubation committee
        recommends the project for graduation
      * Your community can change the project officer as needed (just
        add an agenda item to the next board meeting so they can
        recognise the change of officer).


Access to OSGeo'sMarketing_Committee 
<http://wiki.osgeo.org/wiki/Marketing_Pipeline>is one of the key 
benefits of joining the OSGeo foundation. The Marketing Committee requests:

 1. [marketing.1]Marketing artefacts have been created about the project
    in line with the incubation criteria listed in the OSGeo Marketing
    Committee'sMarketing Artefacts
    <http://wiki.osgeo.org/wiki/Marketing_Artefacts>. This lists the
    documentation requirements forOSGeo-Live <http://live.osgeo.org/>.
    Marketing Artefacts include:
      * [marketing.1a]Application Overview
      * [marketing.1b]Application Quick Start
      * [marketing.1c]Logo
      * [marketing.1d]Graphical Image
 2. [marketing.2]Ideally, stable version(s) of executable applications
    are bundled with appropriate distributions.
    /In most cases, this will at least includeOSGeo-Live
    <http://live.osgeo.org/>, but may also includeDebianGIS
    <https://wiki.ubuntu.com/UbuntuGIS>, and/orosgeo4w
    <http://www.maptools.org/ms4w/>, etc.)/
 3. [marketing.3] The project incorporates OSGeo branding, such as
    including an OSGeo logo on its website.
 4. [marketing.4] The project has been registered with Open HUB, and
    Open HUB has been updated to reference the correct code
    repository(s) for the project.Open HUB
    <https://www.openhub.net/>provides metrics to help assess the health
    of a project.


 1. [projects.1]Projects do not exist in isolation; and are expected to
    communicate and collaborate on key issues.
    /As an example, the PostGIS release procedure asks that the release
    be checked with MapServer, GeoServer and others./
 2. [projects.2] Where applicable, projects are expected to interoperate
    effectively with other applications.
      * [projects.2a] Interoperability is preferably achieved by
        supporting relevant Open Standards.
      * [projects.2b] Where applicable, standards compliance is verified
        by executing compliance tests, such as provided by OGC CITE testing.


  Incubator Application Questionnaire

 1. Please describe your Project.
      * What is its name?
      * What is the home page URL?
      * What does the application do and how does it add value to the
        GeoSpatial stack of software?
      * Does the application make use of OGC standards? Which standards?
        You may wish to add comments about how standards are used.
      * What language(s) are used in this project? (C/Java/perl/etc)
      * What is the dominant written language (i.e. English, French,
        Spanish, German, etc) of the core developers?
      * What type of application does this project represent(client,
        server, standalone, library, etc.)
      * Please provide the name and email address of the principal
        Project Owner. Ref:Project_Graduation_Checklist#board.1
 2. Do you anticipate your project will encounter issues addressing the
    criteria of theProject_Graduation_Checklist
    <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist>? Please
    explain what areas need to be addressed in order to meet this criteria.
      * Please provide the names and emails of co-project owners (if any).
      * Please provide the names, emails and entity affiliation of all
        official committers. Ref:Project_Graduation_Checklist#open.2b
 3. Why is OSGeo Incubation good for your project?
 4. Please describe any relationships to other open source projects.
 5. Please describe any relationships with commercial companies or
    products. Ref:Project_Graduation_Checklist#open.2b
 6. Please explain how your project will use an open governance policy,
    ensuring decisions are made, documented and adhered to in a public
    manner. Ref:Project_Graduation_Checklist#processes.2a
 7. Which open source license(s) will the source code be released under?
 8. Please describe the maturity and history of your project. For instance,
      * How long has your project been producing stable releases?
      * What is the origin of your project (commercial, experimental,
        thesis or other higher education, government, or some other source)?
      * How many people actively contribute (code, documentation,
        other?) to the project at this time?
      * How many people have commit access to the source code
        repository? Ref:Project_Graduation_Checklist#open.2b
      * Approximately how many users are currently using this project?
      * What type of users does your project attract (government,
        commercial, hobby, academic research, etc. )?
 9. Do you wish to host any portion of this project using the OSGeo
    infrastructure? If so, what? Ref:Project_Graduation_Checklist#SAC
10. Does the project support open standards? Which ones and to what
    extent? (OGC, w3c, etc.) Has the software been certified to any
    standard (CITE for example)? If not, is it the intention of the
    project owners to seek certification at some point?
11. Is the code free of patents, trademarks, and do you control the
12. Does the project include an automated build and test?
13. What is the (estimated) size of a full release of this project? How
    many users do you expect to download the project when it is released?
14. Do you already have an OSGeo Mentor to guide you through the
    incubation process?


On 30/11/2014 3:36 am, Jody Garnett wrote:
> Merging docs is a good idea, looks like we end up with one "initial 
> application" document, and one "graduation / checklist" document.
> While merging please keep the checklist feel, we do have a FAQ page 
> which can be used if you feel more discussion is warranted. Questions 
> such as "appropriate standards" are difficult, since we would like to 
> encourage projects to explore and work in areas that have not yet been 
> standardized.
> Jody Garnett
> On Sat, Nov 29, 2014 at 5:49 AM, Cameron Shorter 
> <cameron.shorter at gmail.com <mailto:cameron.shorter at gmail.com>> wrote:
>     Hi all,
>     As I start considering taking OSGeo-Live into OSGeo Incubation,
>     I've audited our Incubation documents which have significant overlap.
>     In particular, I think our Project Graduation Checklist is now
>     quite comprehensive.
>     I believe the General Principles of Incubation document can be
>     retired, as material in it is covered by the Checklist.
>     I think we probably should also retire the Incubation Application
>     Questionnaire, moving a few project specific questions into the
>     Project Graduation Checklist.
>     To show the level of duplication between documents, I've inserted
>     cross references into:
>     http://wiki.osgeo.org/wiki/General_Principles_of_Incubation
>     http://wiki.osgeo.org/wiki/Incubator_Application_Questionnaire#Questions
>     These link to points in:
>     http://wiki.osgeo.org/wiki/Project_Graduation_Checklist
>     In doing this, I've also picked up some limitations with
>     Graduation Checklist:
>     1. There is no question to see if there is feature complete,
>     mature code, with at least one stable release.
>     2. There is no question to see if appropriate standards are being
>     used.
>     3. While there are questions about developer and their
>     affiliations, there isn't a question about the size of the user base.
>     4. We should move some of the "About this project" questions into
>     the Checklist, to keep them in the same place.
>     I'm interested to hear comment on whether merging docs into one is
>     a good idea. If there is rough consensus that it is good, I'll put
>     a proposal forward for a v3 Graduation Checklist.
>     -- 
>     Cameron Shorter,
>     Software and Data Solutions Manager
>     LISAsoft
>     Suite 112, Jones Bay Wharf,
>     26 - 32 Pirrama Rd, Pyrmont NSW 2009
>     P +61 2 9009 5000 <tel:%2B61%202%209009%205000>,  W
>     www.lisasoft.com <http://www.lisasoft.com>,  F +61 2 9009 5099
>     <tel:%2B61%202%209009%205099>
>     _______________________________________________
>     Incubator mailing list
>     Incubator at lists.osgeo.org <mailto:Incubator at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/incubator

Cameron Shorter,
Software and Data Solutions Manager
Suite 112, Jones Bay Wharf,
26 - 32 Pirrama Rd, Pyrmont NSW 2009

P +61 2 9009 5000,  W www.lisasoft.com,  F +61 2 9009 5099

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20141130/25df0fc4/attachment-0001.html>

More information about the Incubator mailing list