[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