[Incubator] code of conduct addition to incubation

[Jody Garnett]

grabbing this out into a seperate thread (rather than make things
complicated).

While not approved by the incubation committee, I have added suggestions
> for a next version of the incubation list here:
> https://wiki.osgeo.org/wiki/Project_Graduation_Checklist
> While nothing on this list should prevent current incubation, I suggest
> running your eye over it and see if there is anything else worth addressing.
> In particular, I suggest that somewhere in your processes you link to the
> OSGeo code of condu


Going through the stuff in red, which I assume is your most recent
additions:

[open.2d] Users are supported and encouraged, via an email list or similar.
- I had assumed that "[open.2a] The project should have a community of
developers and users who actively collaborate and support each other in a
healthy way. " would cover this?

[processes.4] The project has a Code of Conduct. This may be a reference to
the OSGeo Code of Conduct.
- I wonder if this belongs under "open" rather than process?
- I also recognize that a code of conduct is one tool out of many for a
project to work on being inclusive?
- I have not seen the osgeo code of conduct discussed much at the project
level? I kind of viewed he OSGeo code of conduct as applicable to all
committees, mailing lists and projects (and thus not a subject for
incubation as you have outlined here?)

[documentation.3] The project has deployment documentation:
[documentation.3a] Including, where appropriate, how to deploy, configure
and optimise the application.
- I find this covered under "[documentation.1] The project has user
documentation:" - for a server application the user documentation would be
directed at the system administrator. I know the language is confusing with
a sys admin being responsible for standing up a service which is made
available to "users".

[release.1a] Which supports both stable and development releases.
[release.4] The project has released stable, feature complete releases.
- this is getting too much, asking that a project make releases is one
thing, asking that a team maintain multiple concurrent versions suitable
for public consumption is a bit too far
- making the source code available, and instructions for how to build, are
enough for any party interested in trying our the latest development
- (nightly build is preferable to development releases anyways so that the
community can benifit from rapid feedback)

I am leaving off the other items as they require collaboration with the
respective committees.



--
Jody Garnett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20160906/a1aae184/attachment.html>