Open Stack

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.

Plus, enterprise adoption of the open cloud *requires* 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.



*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Mon, Oct 6, 2014 at 8:40 AM, Zane Bitter <zbitter at redhat.com> wrote:

> On 06/10/14 06:07, Thierry Carrez wrote:
>
>> Jay Pipes wrote:
>>
>>> On 10/03/2014 09:18 PM, Zane Bitter wrote:
>>>
>>>> The prospect of a much larger tent with many more projects in
>>>> OpenStack-proper shines a spotlight on the scalability of the Docs team,
>>>> and in particular how they decide which projects are "important" to work
>>>> on directly.
>>>>
>>>
>>> I don't believe that a ticket to live under the OpenStack tent should
>>> come with the expectation that the Docs team is required to write
>>> documentation for the project.
>>>
>>> IMHO, it should be up to the project itself to provide the resources to
>>> work *under the guidance* of the Docs team to write developer, end user
>>> and operator documentation. The Docs team members should be able to play
>>> an advisory role for new projects, helping them understand the automated
>>> doc processes, the way that common doc infrastructure works, and
>>> techniques for writing useful documentation consistent with other
>>> projects.
>>>
>>
>> I'd like to generalize that beyond Docs, because the same issue applies
>> to all other horizontal teams.
>>
>> There are multiple ways an horizontal team can declare its commitment,
>> and I agree we should never assume that a TC decision ("new integrated
>> project!") implies more work for the team ("Docs now has to support this
>> as well"). That's the way it currently works, and yes, it doesn't scale.
>> It didn't scale early with Docs, so they opted out of "supporting all
>> integrated projects" early on.
>>
>> So in summary:
>> - ticket to live under the OpenStack big tent should never come with
>> expectation that any horizontal team will do the work for that project
>> directly
>> - horizontal teams may decide to directly do the work for any number of
>> projects
>> - corollary #1: horizontal teams may decide to commit to directly doing
>> the work for a mostly-static "ring0" (or not)
>> - corollary #2: horizontal teams may decide to not directly do the work
>> for any project
>> - horizontal teams should build processes and tools to facilitate and
>> guide the work of projects in the big tent in their area of expertise
>>
>
> +1
>
> 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?
>
> cheers,
> Zane.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141006/374957ad/attachment.html>