<div dir="ltr">I personally believe that delegating the task of documentation to individual projects would be a huge mistake for one big reason: documentation exists to understand how everything works within the context of the solution as a whole. Very hard to do that consistently across all projects with the docs team entrenched in developing individual products.<div><br class="">Plus, enterprise adoption of the open cloud <i>requires</i> documentation that isn't an after thought. Writing code and trying to set aside some time to document is the sheer definition of turning documentation an afterthought - and no superior product has ever come from that sort of model.<div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial"><br></div><div style="font-family:arial;font-size:small">AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div><div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: +1 302-387-4660</div></font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">Direct: +1 916-246-2072</div></font></font></div></font></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39"><br></div></div></div>
<br><div class="gmail_quote">On Mon, Oct 6, 2014 at 8:40 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/10/14 06:07, Thierry Carrez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/03/2014 09:18 PM, Zane Bitter wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The prospect of a much larger tent with many more projects in<br>
OpenStack-proper shines a spotlight on the scalability of the Docs team,<br>
and in particular how they decide which projects are "important" to work<br>
on directly.<br>
</blockquote>
<br>
I don't believe that a ticket to live under the OpenStack tent should<br>
come with the expectation that the Docs team is required to write<br>
documentation for the project.<br>
<br>
IMHO, it should be up to the project itself to provide the resources to<br>
work *under the guidance* of the Docs team to write developer, end user<br>
and operator documentation. The Docs team members should be able to play<br>
an advisory role for new projects, helping them understand the automated<br>
doc processes, the way that common doc infrastructure works, and<br>
techniques for writing useful documentation consistent with other projects.<br>
</blockquote>
<br>
I'd like to generalize that beyond Docs, because the same issue applies<br>
to all other horizontal teams.<br>
<br>
There are multiple ways an horizontal team can declare its commitment,<br>
and I agree we should never assume that a TC decision ("new integrated<br>
project!") implies more work for the team ("Docs now has to support this<br>
as well"). That's the way it currently works, and yes, it doesn't scale.<br>
It didn't scale early with Docs, so they opted out of "supporting all<br>
integrated projects" early on.<br>
<br>
So in summary:<br>
- ticket to live under the OpenStack big tent should never come with<br>
expectation that any horizontal team will do the work for that project<br>
directly<br>
- horizontal teams may decide to directly do the work for any number of<br>
projects<br>
- corollary #1: horizontal teams may decide to commit to directly doing<br>
the work for a mostly-static "ring0" (or not)<br>
- corollary #2: horizontal teams may decide to not directly do the work<br>
for any project<br>
- horizontal teams should build processes and tools to facilitate and<br>
guide the work of projects in the big tent in their area of expertise<br>
</blockquote>
<br></div></div>
+1<br>
<br>
So it seems like there is general agreement that we don't need/want the TC to tell horizontal teams what to work on, and that isn't one of the reasons for "ring0"/"ring compute"/"Layer 1" to be a thing?<br>
<br>
cheers,<br>
Zane.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>