[Incubator] Steps toward merging/deprecating incubation documents
Jody Garnett
jody.garnett at gmail.com
Mon Jan 26 14:37:01 PST 2015
I would be happy to hold an IRC (or Skype meeting). Would like to ensure
all parties have a chance to read the resulting document first (as I hate
shared editing sessions).
While I was unavailable on the 15th, perhaps we could meet later this week:
*
http://www.timeanddate.com/worldclock/meetingdetails.html?month=1&day=29&year=2015&hour=18&min=30&sec=0&p1=179&p2=189&p3=224&p4=22&p5=240&p6=196&p7=215
My initial feedback is that the "review template" is nice and clear, would
like to capture the review at a module or package level (rather than
blindly list every file in the codebase, we would like to highlight the
exceptions that required action). Ideally this level of detail could be
maintained by a project after incubation as part of each major release.
I have learned a bit (as GeoTools was subject to external reviews). The
goal of "and that the code is all under the Project license." may be
softened to "code all under an open source license". We found files that
had been copied from external projects needed to retain their original
header and license. If they were subsequently modified the project license
would also apply. Indeed you can see examples of this in the geotools
review, and in our users guide
<http://docs.geotools.org/latest/userguide/welcome/license.html>.
--
Jody Garnett
On 16 December 2014 at 12:02, Cameron Shorter <cameron.shorter at gmail.com>
wrote:
> 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 documents. 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> 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 <%2B61%202%209009%205000>, W www.lisasoft.com, F +61
>>> 2 9009 5099 <%2B61%202%209009%205099>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> --
> 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
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20150126/4ff885cd/attachment-0001.html>
More information about the Incubator
mailing list