[Incubator] Steps toward merging/deprecating incubation documents
Jody Garnett
jody.garnett at gmail.com
Wed Dec 3 13:58:25 PST 2014
Sorry Cameron two many small changes for a prompt email reply.
In general several additions appear to be setting the bar higher (for a
given concern) rather then simply clarifying. Open 2b has been tweaked with
more requirements about sustainability, this is a bit off topic as we cover
that later do we not?
There is also examples of overlap (some overlap between 1c and 2c).
Jody Garnett
On Sat, Nov 29, 2014 at 4:49 PM, Cameron Shorter <cameron.shorter at gmail.com>
wrote:
> 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.
>
> http://wiki.osgeo.org/wiki/Project_Graduation_Checklist
> Project Graduation Checklist
> Open
>
> 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, support and direction from multiple
> developers, power users, and/or sponsors, 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
> <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 a Provenance Review
> <http://www.osgeo.org/incubator/process/codereview.html>.
> 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
> archived.
>
> Processes
>
> 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 documented and follows its management
> processes.
> *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.*
>
> Documentation
>
> 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 application.
> 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
> testing.*
> - [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.
> Board
>
> The OSGeo Board <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
> <http://wiki.osgeo.org/wiki/Contacts#Software_Projects>
> - 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).
>
> Marketing
>
> Access to OSGeo's Marketing_Committee
> <http://wiki.osgeo.org/wiki/Marketing_Committee> and associated
> Marketing_Pipeline <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's Marketing Artefacts
> <http://wiki.osgeo.org/wiki/Marketing_Artefacts>. This lists the
> documentation requirements for OSGeo-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 include OSGeo-Live
> <http://live.osgeo.org/>, but may also include DebianGIS
> <http://wiki.debian.org/DebianGis>, UbuntuGIS
> <https://wiki.ubuntu.com/UbuntuGIS>, and/or osgeo4w
> <http://trac.osgeo.org/osgeo4w/> ms4w <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.
>
> Projects
>
> 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.
>
>
> http://wiki.osgeo.org/wiki/Incubator_Application_Questionnaire
> 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
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#board.1>
> 2. Do you anticipate your project will encounter issues addressing
> the criteria of the Project_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
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#open.2b>
> 3. Why is OSGeo Incubation good for your project?
> 4. Please describe any relationships to other open source projects.
> Ref: Project_Graduation_Checklist#Projects
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#Projects>
> 5. Please describe any relationships with commercial companies or
> products. Ref: Project_Graduation_Checklist#open.2b
> <http://wiki.osgeo.org/wiki/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
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#processes.2a>
> 7. Which open source license(s) will the source code be released
> under? Ref: Project_Graduation_Checklist#open.1a
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#open.1a>
> 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? Ref:
> Project_Graduation_Checklist#open.2b
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#open.2b>
> - How many people have commit access to the source code repository?
> Ref: Project_Graduation_Checklist#open.2b
> <http://wiki.osgeo.org/wiki/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
> <http://wiki.osgeo.org/wiki/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? Ref:
> Project_Graduation_Checklist#projects.2
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#projects.2>
> 11. Is the code free of patents, trademarks, and do you control the
> copyright? Ref:
> Project_Graduation_Checklist#Project_Graduation_Checklist#Copyright_and_License
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#Project_Graduation_Checklist.23Copyright_and_License>
> 12. Does the project include an automated build and test? Ref:
> Project_Graduation_Checklist#release.2
> <http://wiki.osgeo.org/wiki/Project_Graduation_Checklist#release.2>
> 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?
>
>
> Deprecate:
> http://wiki.osgeo.org/wiki/General_Principles_of_Incubation
>
>
> 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> 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, W www.lisasoft.com, F +61 2 9009 5099
>>
>> _______________________________________________
>> Incubator mailing list
>> Incubator at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/incubator
>>
>
>
> --
> 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, W www.lisasoft.com, F +61 2 9009 5099
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20141203/c321bf09/attachment-0001.html>
More information about the Incubator
mailing list