[Incubator] Steps toward merging/deprecating incubation documents
Cameron Shorter
cameron.shorter at gmail.com
Fri Dec 5 11:11:18 PST 2014
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, W www.lisasoft.com, F +61 2 9009 5099
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20141206/d1715a34/attachment-0001.html>
More information about the Incubator
mailing list