<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 26, 2015 at 1:45 PM, Stefano Maffulli <span dir="ltr"><<a href="mailto:stefano@openstack.org" target="_blank">stefano@openstack.org</a>></span> wrote:<br><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">On Wed, 2015-02-25 at 21:15 +0000, Ian Cordasco wrote:<br>
> I read it the same was as Doug. I don’t think Jeremy was trying to<br>
> imply your reviews would move through more quickly if you reviewed<br>
> other people’s work. Just that, as with most open source projects,<br>
> there’s always at least 2 distinct groups: people who push code more<br>
> often and people who review code more often.<br>
<br>
this conversation reminded me that the median time to merge new code has<br>
been increasing every quarter in the past year, but dropped for the<br>
first time during last quarter (table and chart on page 23 of Q4<br>
quarterly report [1]). The mean number of iterations (patchsets) per<br>
proposed change has also decreased for the first time in Q4 2014.<br>
<br>
The interesting bit of those charts is that overall for OpenStack<br>
projects, it seems that the reviews (comments to patchsets) are arriving<br>
quite quickly but the new patchsets take a lot more to be submitted.<br>
<br>
Too much debating and commenting over each patch? Or are the<br>
authors/owners of the changeset slow to respond with new patches? I<br>
don't have an answer. I'd be happy to look at the data with other<br>
people.<br>
<br>
I think more analysis is needed before we can identify and remove the<br>
problem.<br>
<br>
/Stef<br>
<br>
 [1]<br>
<a href="http://git.openstack.org/cgit/openstack-infra/activity-board/plain/reports/2014-q4/pdf/2014-q4_OpenStack_report.pdf" target="_blank">http://git.openstack.org/cgit/openstack-infra/activity-board/plain/reports/2014-q4/pdf/2014-q4_OpenStack_report.pdf</a><br>
The analysis doesn't count the *-specs repositories, only code and docs.<br>
<br></blockquote><div><br></div><div>Thanks for the analysis Stef. One additional analysis I would like to see is this:</div><div><br></div><div>Do the features listed in the Release Notes each have appropriate documentation? So far we just link to the specifications for nova, for example. [1] So to me, it could be a focus on the specification acceptance means less time/energy for the actual user-facing docs.</div><div><br></div><div>What could I do to analyze and correlate the feature completeness to doc completeness? A desire to release docs with code is great but we don't seem to be doing so in the way that I define docs being done. </div><div><br></div><div>I've worked with Agile teams in the past, and you have to put your definition of done for docs in with the code. Often times, it's "release notes only" in the definition of done. So I think we're working at that level of "done" for docs, instead of "end user docs complete" or "API docs complete" or "config docs complete" or "administration documented" as the marker of complete for release. </div><div><br></div><div>We've seen with the python-<project>clients that the docs are very much complained about. The release cadence doesn't really give docs a chance to do anything but scrape the help text to automate a collection of information about each command in the CLI Reference. [2] That's one solution but one that serves speed rather than quality. Users tell me they'd prefer to have commands for use cases and scenarios in the docs, which is closer to our End User Guide. [3] But even the End User Guide could be improved by showing examples of what's returned for each command. We've only got about 10% coverage there. </div><div><br></div><div>We're doing everything we can to make it easier to contribute to docs by migrating to RST,[4] so let's please consider an energy transfer from specs acceptance to end-user docs, especially during feature freeze time.</div><div><br></div><div>Kept meaning to note the difficulties for docs on the other thread, but Stef's email reminds me we need more analysis as well.</div><div>Thanks,</div><div>Anne</div><div><br></div><div>1. <a href="https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Compute_.28Nova.29">https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Compute_.28Nova.29</a></div><div>2. <a href="http://docs.openstack.org/cli-reference/content/">http://docs.openstack.org/cli-reference/content/</a></div><div>3. <a href="http://docs.openstack.org/user-guide/content/">http://docs.openstack.org/user-guide/content/</a></div><div>4. <a href="http://justwriteclick.com/2015/02/23/state-of-the-migration-to-sphinxrst/">http://justwriteclick.com/2015/02/23/state-of-the-migration-to-sphinxrst/</a></div><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">
PS The analysis of the individual projects are in their own pdf<br>
<a href="http://git.openstack.org/cgit/openstack-infra/activity-board/tree/reports/2014-q4/pdf/projects" target="_blank">http://git.openstack.org/cgit/openstack-infra/activity-board/tree/reports/2014-q4/pdf/projects</a><br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Anne Gentle<br><a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a></div>
</div></div>