<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 12:52 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</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"><div class=""><div class="h5">On 10/06/2014 01:39 PM, Adam Lawson 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">
I like your suggestion about the Docs team being advisors. I would<br>
submit however (my opinion here) that whether or not there are enough<br>
resources on the Doc'n team to handle Openstack's current list of<br>
integrated programs, offloading the work to individual projects<br>
exchanges one challenge (scalability) with another problem (quality).<br>
Using that approach, doc bugs will get triaged with the other project<br>
bugs and potentially distracts developers from doing what they do best -<br>
writing and fixing code. And what happens when you only have time to fix<br>
a feature or work on documentation? Focus on features and<br>
performance/stability are going to win. Every time. And they should<br>
because that what the program teams should be focused on. That means we<br>
start down the road heavy on code because developers can't do<br>
everything, making them light on documentation forcing a catch-up<br>
process to ensure which requires a special team to preserve momentum,<br>
bringing us back to where we are now. I've been there before. And I'm<br>
sure others have as well.<br>
<br>
I've always been a big proponent of exploiting strengths vs building on<br>
weaknesses and I'm going to step out on a limb here and speak to<br>
strengths which may get me into hot water with some so I want to<br>
apologize in advance. ; )<br>
<br>
If a team of developers is tasked to produce all of the documentation<br>
for enterprise consumers, I hate to say it like this but you'll end up<br>
with highly-targeted documentation that makes sense to a developer and<br>
possibly low-level engineers. That level of detail is probably best<br>
served in README, wikis and mailing lists. It isn't effective as a<br>
user's manual. Even with coaching, we'd be coaching folks to do things<br>
they aren't good at. Same goes for a solution architect writing<br>
documentation the other way around - you end up with documentation that<br>
speaks so broad, it fails to make the impact that a targeted/focused<br>
approach is needed by the engineering consumers.<br>
<br>
While documentation produced by each individual project makes a special<br>
kind of impact, it must be one spoke - not the entire wheel. I love the<br>
idea of advisors and they should provide the first draft but I also<br>
believe a dedicated team is needed to ensure quality doesn't suffer.<br>
</blockquote>
<br></div></div>
I guess I wasn't clear in my suggestion. I am proposing that the joining project be responsible for bringing resources to the table -- and not developer resources, but tech writer resources. I think developers can and should work with the Docs team, but I also think that projects should hire or source tech writers themselves to handle the end user and operator documentation.<br></blockquote><div><br></div><div>This is happening with some projects and I always encourage companies hiring for OpenStack devs should also hire writers to keep up with those devs. </div><div><br></div><div>Sometimes the tech writer is assigned only to the API docs not the operator docs. Or all sorts of other combinations. But yes, the idea is that the enterprise doc teams should also dedicate some of their work to upstream patching. </div><div><br></div><div>And yes, I agree with the sentiment that it's pretty useless to document any project standalone for anyone except contributor devs. Users, operators, should write for users and operators upstream. Contrib devs write for devs in the commuity/upstream. Also hire tech writers who are good at advocating for particular groups and have them write for upstream as well. Lana Brindley and I are talking about that at the Summit Monday at 17:10 <a href="http://sched.co/1qeSZbp">http://sched.co/1qeSZbp</a></div><div><br></div><div>Nick Chase and I are working on a report about the balance between meeting the needs of community doc contributors and finding resources for enterprise-level deliverables. It's complicated, isn't it? It's a balancing act. </div><div> </div><div>Great discussion.</div><div>Anne</div><div><br></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">
<br>
Best,<br>
-jay<div class=""><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></div>