[Incubator] Steps toward merging/deprecating incubation documents

Cameron Shorter cameron.shorter at gmail.com
Tue Dec 16 12:01:22 PST 2014


Ok,
I've now reviewed the Provenance Review document [1]. This previously 
referenced a "Provenance Review Template (not created yet, use existing 
review documents as a guide)".

I've now created such a template [2] and referenced from the draft 
Provenance Review document, (as well as fixing some very trivial 
formatting errors).

I'd appreciate a review of the template before I start using if for the 
OSGeo-Live project.

Jody,
I'd also propose that we hold a IRC meeting of the incubation committee 
mid January to approve these updates to the incubation process. Ideally 
comments for changes will be in place before then.

Say 15/16 January:
http://www.timeanddate.com/worldclock/meetingdetails.html?month=1&day=15&year=2015&hour=18&min=30&sec=0&p1=179&p2=189&p3=224&p4=22&p5=240&p6=196&p7=215

[1] http://wiki.osgeo.org/wiki/Code_Provenance_Review
[2] http://wiki.osgeo.org/wiki/Provenance_Review_Template

On 6/12/2014 6:11 am, Cameron Shorter wrote:
> Thanks for the feedback Jody. Comments inline.
>
> On 4/12/2014 8:28 am, Jody Garnett wrote:
>> Sorry Cameron two many small changes for a prompt email reply.
> Understood.
>>
>> In general several additions appear to be setting the bar higher (for 
>> a given concern) rather then simply clarifying.
> It may appear so, but I think in most cases, I've just copied criteria 
> from either one of the other OSGeo Incubation documents, or the 
> OSGeo-Live "how to add a project" criteria (which is one of the 
> referenced criteria for Incubation).
>
> I can see 2 instances where you might consider the incubation process 
> slightly extended, but I expect all incubated projects would meet this 
> as it is best practice and worthy of including in an update:
>
>  1. [documentation.3] The project has deployment documentation:
>       * [documentation.3a] Including, where appropriate, how to
>         deploy, configure and optimise the application.
>
> [projects.2b] Where applicable, standards compliance is verified by 
> executing compliance tests, such as provided by OGC CITE testing.
>
> Beyond what you have mentioned below, do you have any other concerns?
>> Open 2b has been tweaked with more requirements about sustainability, 
>> this is a bit off topic as we cover that later do we not?
> /[open.2b]////Long term viability of the project is demonstrated by 
> showing participation,////support////and direction from multiple 
> developers,////*and/or* power users, and/or sponsors//, who come from 
> multiple organisations.///
>
> I have extended this a bit to reflect the reality that participation 
> need not be limited to developers, and indeed self help can come from 
> users and sponsors. (I've added another "and/or" above in bold to make 
> this clearer)
>
> I can't find where this is covered later on, can you please reference 
> if you can see it.
>>
>> There is also examples of overlap (some overlap between 1c and 2c).
> This is true. (This is also true in our previous version 2.0 of the 
> document.) I'm ok with removing one, probably 2c, but would be more 
> inclined to leave it as is.
>
> Jody,
> If there are other additions which you think need discussion, then 
> please mention them.
>
>>
>> Jody Garnett
>>
>> On Sat, Nov 29, 2014 at 4:49 PM, Cameron Shorter 
>> <cameron.shorter at gmail.com <mailto: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,supportand
>>             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 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 <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 documentedand followsits
>>         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 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
>>             <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'sMarketing_Committee
>>     <http://wiki.osgeo.org/wiki/Marketing_Committee>and
>>     associatedMarketing_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'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
>>         <http://wiki.debian.org/DebianGis>,UbuntuGIS
>>         <https://wiki.ubuntu.com/UbuntuGIS>, and/orosgeo4w
>>         <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 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
>>             <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 <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
>>     LISAsoft
>>     Suite 112, Jones Bay Wharf,
>>     26 - 32 Pirrama Rd, Pyrmont NSW 2009
>>
>>     P+61 2 9009 5000  <tel:%2B61%202%209009%205000>,  Wwww.lisasoft.com  <http://www.lisasoft.com>,  F+61 2 9009 5099  <tel:%2B61%202%209009%205099>
>>
>>
>
> -- 
> 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,  Wwww.lisasoft.com,  F +61 2 9009 5099

-- 
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/20141217/82f8f579/attachment-0001.html>


More information about the Incubator mailing list