[Incubator] Steps toward merging/deprecating incubation documents
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
/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
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
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
* [processes.2a]The project has a suitable open governance policy
ensuring decisions are made, documented and adhered to in a
/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
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.
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
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
<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.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
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
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
6. Please explain how your project will use an open governance policy,
ensuring decisions are made, documented and adhered to in a public
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
* 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
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
> 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:
> These link to points in:
> 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
> 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
> 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
> Incubator mailing list
> Incubator at lists.osgeo.org <mailto:Incubator at lists.osgeo.org>
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...
More information about the Incubator