<div dir="ltr">There should be examples of existing projects and our graduation checklist.<div><br></div><div>The code review is pretty minimal, checking headers and producing a set of known problems. If it helps the intended audience is the OSGeo board, and to a lesser extent potential users (who can use the list of know issues when performing audit/risk assessment).</div><div><br></div><div>We had a lot of frustration at the start of OSGeo with automated header checking. Ended up asking projects to manually review each file (best done as a team over a couple days). For GeoServer we did both grep and manual (see <a href="https://github.com/geoserver/geoserver/wiki/GeoServer%20Provenance%20Review">GeoServer Provenance Review</a>).</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div>Jody Garnett</div></div></div>
<br><div class="gmail_quote">On Tue, Sep 30, 2014 at 2:14 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mardi 30 septembre 2014 18:08:30, Jody Garnett a écrit :<br>
<span class="">> I was trying to think what an incubation sprint would look like .. am I<br>
> correct in assuming that "code review" is the sticking point?<br>
<br>
</span>Jody,<br>
<br>
What kind of "code review" ? Checking that all source files have a license text<br>
in their header ? Or something more involved ?<br>
Regarding licences, I'm wondering if there are not tools that could do an<br>
automated summary. There are definitely proprietary ones, but I couldn't find<br>
free software ones right away with my very quick search.<br>
<br>
Even<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> In any case two ideas:<br>
><br>
> 1) A general cross project sprint where we gather up developers from<br>
> several projects, along with their mentors and try and power through<br>
> checking the code. It is good value as projects will encounter  similar<br>
> questions and have a chance to learn from each other etc... This is great<br>
> for community building but represents large sponsorship cost as we are<br>
> assured of getting developers from different corners of the globe.<br>
><br>
> 2) The other way to play is to focus on a project at a time, and see if we<br>
> can sponsor the project mentor to "crash" an existing code sprint. This may<br>
> be better for projects with a lot of developers in the same part of the<br>
> world?<br>
><br>
> Finally I a not sure if remote (via Skype) sprints are going to cut it. It<br>
> is too easy to get dragged away by your "day job" and not focus on team<br>
> members who are waiting. It slows down the whole thing and lacks focus.<br>
><br>
> Any ideas/thoughts? I would be keen to hear from graduated projects on "how<br>
> they did it" - perhaps we can learn what worked and structure a "sprint"<br>
> around that activity.<br>
> --<br>
> Jody Garnett<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
</font></span></blockquote></div><br></div>