<div dir="ltr">grabbing this out into a seperate thread (rather than make things complicated).<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">While not approved by the incubation committee, I have added suggestions for a next version of the incubation list here:<br><a href="https://wiki.osgeo.org/wiki/Project_Graduation_Checklist">https://wiki.osgeo.org/wiki/Project_Graduation_Checklist</a><br>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.<br>In particular, I suggest that somewhere in your processes you link to the OSGeo code of condu</blockquote><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div><br></div><div>Going through the stuff in red, which I assume is your most recent additions:</div><div><br></div><div>[open.2d] Users are supported and encouraged, via an email list or similar.<br></div><div>- 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?</div><div><br></div><div><div>[processes.4] The project has a Code of Conduct. This may be a reference to the OSGeo Code of Conduct.</div></div><div>- I wonder if this belongs under "open" rather than process?</div><div>- I also recognize that a code of conduct is one tool out of many for a project to work on being inclusive?</div><div>- 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?)</div><div><br></div><div><div>[documentation.3] The project has deployment documentation:</div><div>[documentation.3a] Including, where appropriate, how to deploy, configure and optimise the application.</div></div><div>- 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".</div><div><br></div><div>[release.1a] Which supports both stable and development releases.<br></div><div><div>[release.4] The project has released stable, feature complete releases.</div><div>- 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</div></div><div>- making the source code available, and instructions for how to build, are enough for any party interested in trying our the latest development</div><div>- (nightly build is preferable to development releases anyways so that the community can benifit from rapid feedback)</div><div><br></div><div>I am leaving off the other items as they require collaboration with the respective committees.</div><div><br></div><div><br></div><div><br></div><div>--</div><div>Jody Garnett</div></div></div></div></div>
</div></div>