IstSOS Incubation Graduation Checklist

This page has moved

• https://trac.osgeo.org/osgeolive/wiki/Incubator%20Application
• https://trac.osgeo.org/osgeolive/wiki/Graduation%20List

Incubator Application Questionnaire version 2.0

Questions from the Incubator Application Questionnaire version 2.0.

1. Please provide the name and email address of the principal Project Owner.
   massimiliano dot cannata AT gmail X com
2. Please provide the names and emails of co-project owners (if any).
   [TODO] Refer to members of the TODO.
3. Please provide the names, emails and entity affiliation of all official committers.
   [TO BE UPDATED] Refer to https://github.com/massimiliano-cannata/istsos2/blob/master/COMMITTERS.txt
4. Please describe your Project.
   istSOS is an OGC SOS server implementation written in Python. istSOS allows to collect, manage and share observations from monitoring sensors according to the Sensor Observation Service standard. Along to the SOS specification, istSOS offers a number of extending features accessible trough it web admin interface and its RESTful API like data aggregation, virtual procedures, time zone reprojection, authentication and authorization, json and csv output format, and others.
5. Why is OSGeo Incubation good for your project?
   We wish to officially demonstrate the level of quality of the project.
6. What type of application does this project represent(client, server, standalone, library, etc.):
   istSOS is a server application, even if an administration interface is available with the package (i.e.:similarly to geoserver).
7. Please describe any relationships to other open source projects.
   [TO COMPLETE] istSOS is part of the OSGeo-Live project.
8. Please describe any relationships with commercial companies or products.
   WHat is the scope of this question? why not relation with government or accademy? this soud discriminatory
9. Please explain how your project will use an open governance policy, ensuring decisions are made, documented and adhered to in a public manner.
   [TODO] All decisions are currently made at istSOS PSC meetings whose minutes is publicly shared for comments and further discussion.

1. Which open source license(s) will the source code be released under?
   The licenses used for the OSGeo-Live build scripts and documentation are: Creative Commons Attribution-ShareAlike 3.0 Unported License for Quickstarts, Creative Commons Attribution 3.0 Unported License for Project Overviews, LGPL version >=2.1 for the install scripts, One of the OSI approved Open Source licenses for installed applications, Public domain, CC-By-SA, and Open Data Commons Open Database License (ODbL) for data
2. Please describe the maturity and history of your project. For instance,
   • What is the origin of your project (commercial, experimental, thesis or other higher education, government, or some other source)?
     OSGeo-Live was initially developed as a promotional distribution for handing out at FOSS4G conferences and the like, and has since grown, especially into supporting educational programs.
   • How many people actively contribute (code, documentation, other?) to the project at this time?
     Literally hundreds of people, as per: http://live.osgeo.org/en/sponsors.html
   • How many people have commit access to the source code repository?
     Literally hundreds of people, as per: http://live.osgeo.org/en/sponsors.html
   • Approximately how many users are currently using this project?
     Probably tens of thousands of people per year are exposed to OSGeo-Live at conferences around the world.
   • What type of users does your project attract (government, commercial, hobby, academic research, etc. )?
     Primarily people new to OSGeo software who want to know more.
3. Do you wish to host any portion of this project using the OSGeo infrastructure? If so, what?
   We are already using some of OSGeo hosting, in particular, the OSGeo Issue tracker.
4. 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?
   There are many projects which OSGeo-Live packages which follow OGC standards. Most OGC standards are covered. To a certain extent, OSGeo-Live follows debian packaging conventions.
5. Is the code free of patents, trademarks, and do you control the copyright?
   OSGeo-Live is free of patents and trademarks. Copyright is owned by numerous people and organisations who have contributed to OSGeo-Live.
6. Does the project include an automated build and test?
   The build process is mostly automated. Automated testing is not very feasible for an integration project such as OSGeo-Live, and as such most testing is manual.
7. What language(s) are used in this project? (C/Java/perl/etc)
   Most of OSGeo-Live code is shell scripts for installing applications. The packages we bundle are written in numerous languages.
8. What is the dominant written language (i.e. English, French, Spanish, German, etc) of the core developers?
   Primary document is English. Documentation is translated into over 10 languages.
9. 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?
   Our distribution aims to fit on a 4Gig USB or DVD for a mini distribution, or 8 Gig USB for full distribution.
10. Do you already have an OSGeo Mentor to guide you through the incubation process?
    Yes, Jody Garnett.

OSGeo-Live Incubation Checklist

This page addresses the status of OSGeo-Live as per version 2.0 of the OSGeo Incubation Checklist. It is derived from the wiki version of the document.

For the purposes of incubation auditing, the scope of the OSGeo-Live project comprises of the scripts and processes used to build OSGeo-Live, but doesn't include the specific projects being packages (many of which are addressing OSGeo Incubation separately in their own right).

Incubation Checklist

Open

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

1. Open: projects are expected to function in an open and public manner and include:
   • Open source license(s),
     • YES: Code is under LGPL, Documentation under Creative Commons, as per http://live.osgeo.org/en/copyright.html
   • Open communication channels,
     • YES: We have an active email list, and hold weekly IRC meetings during build cycles. http://wiki.osgeo.org/wiki/Live_GIS_Disc#Contact_Us
   • Open decision making process,
     • YES: Decision making process is documented at https://wiki.osgeo.org/wiki/Live_GIS_Management
2. Active and healthy community:
   • 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.
     • YES: A few hundred people have contributed to OSGeo-Live. Most contributions have been in writing application installer scripts, associated documentation, as well as translations. A list of contributors are at: http://live.osgeo.org/en/sponsors.html
   • Long term viability of the project is demonstrated by showing participation and direction from multiple developers, who come from multiple organisations.
     Eg. The project is resilient enough to sustain loss of a developer or supporting organisation, often referred to as having a high bus factor. 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.
     • YES: Contributors come from a wide range of organisations (as seen by email addresses of contributors). Sponsoring organisations are also listed at: http://live.osgeo.org/en/sponsors.html

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. All project source code is available under an Open Source license.
   YES: Code is under LGPL, as per http://live.osgeo.org/en/copyright.html
2. Project documentation is available under an open license, such as Creative Commons.
   YES: Documentation is under Creative Commons licence, as per http://live.osgeo.org/en/copyright.html
3. The project code, documentation and data has been adequately vetted to assure it is all properly licensed, and a copyright notice included, as per a [http://www.osgeo.org/incubator/process/codereview.html Provenance Review.
   TBD: Provenance Review is required.
4. The project maintains a list of all copyright holders identified in the Provenance Review Document.
   YES: All contributors are listed at: http://live.osgeo.org/en/sponsors.html
5. All code contributors have agreed to abide by the project's license policy, and this agreement has been documented and archived.
   YES: All contributors have publicly accepted the terms of the OSGeo-Live license. This is archived in the OSGeo-Live email list. The process is described here: http://wiki.osgeo.org/wiki/Live_GIS_Disc#Subversion

Processes

1. The project has code under configuration management.
   Eg, subversion, git.
   YES: http://wiki.osgeo.org/wiki/Live_GIS_Disc#Subversion
2. The project uses an issue tracker and keeps the status of the issue tracker up to date.
   YES: http://wiki.osgeo.org/wiki/Live_GIS_Disc#Issue_Tracker
3. The project has documented its management processes.
   This is typically done within a Developers Guide or Project Management Plan.
   YES: http://wiki.osgeo.org/wiki/Live_GIS_Disc
   • 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.
     Yes, Project Management Committee and management processes are defined at: https://wiki.osgeo.org/wiki/Live_GIS_Management
   • 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.
     YES: http://wiki.osgeo.org/wiki/Live_GIS_Disc#Contact_Us

Documentation

1. The project has user documentation:
   • Including sufficient detail to guide a new user through performing the core functionality provided by the application.
     

YES: The project has extensive Project Overviews and Quickstarts, specifically designed for getting new users up and running quickly. These are linked from: http://live.osgeo.org/en/index.html and http://live.osgeo.org/en/overview/overview.html

1. The project has developer documentation:
   YES: How to add a new project to OSGeo-Live is covered in detail. Linked from: http://wiki.osgeo.org/wiki/Live_GIS_Disc#How_to_add_a_project_to_OSGeoLive
   • Including checkout and build instructions.
     YES: Linked from: http://wiki.osgeo.org/wiki/Live_GIS_Disc#How_to_add_a_project_to_OSGeoLive
   • Including commented code, ideally published for developer use.
     Examples: javadocs for Java applications, or Sphinx documentation for Python applications.
     YES: Code is primarily relatively small shell script files, which include comment.
   • Providing sufficient detail for an experience programmer to contribute patches or a new module in accordance with the project's programming conventions. <br\>YES

Release Procedure

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

1. The project follows a defined release process:
   • Which includes execution of the testing process before releasing a stable release.
     The project has an established build and release process, but it needs to be more clearly documented. Some information here: http://wiki.osgeo.org/wiki/Live_GIS_Disc#Build_Process . The release management role is well established, but not documented. This includes setting up a schedule, sending out press releases, chasing up projects, etc, etc.
2. The project follows a documented testing process.
   Ideally, this includes both automated and manual testing
   Ideally this includes documented conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests.
   OSGeo-Live is an integration project, which is difficult to create automated testing for. Instead we rely on manual testing. The testing process is well practiced, but needs to be documented better.
3. Release and testing processes provide sufficient detail for an experienced programmer to follow.
   TBD: Waiting on improved documentation.