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 <zbit...@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 > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev