<div dir="ltr">No responses here? I'd love to hear your thoughts. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 2:39 PM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<p>Hi all -</p><p>With the new "programs" coming to OpenStack, some documentation will need to be delivered on the same day as the release. We also now have 10 core/integrated projects with 2 more in incubation. Currently the documentation that is delivered on the same day as the release is the contributor docs, maintained by the Python devs (Sphinx/RST) and stored with the code. We have separate repos for API docs and operator docs, but the review processes are the same as the code. As you can imagine, I'm looking for ideas for this brave new world.<br>
</p>
<p>Specifically, here are some questions I want to ask all of you for inspiration and ideas:</p>
<ol>
<li>What's the most important lesson you've learn about motivating developers to write user documentation? Who taught it to you and how? </li>
<li>What's the most difficult issue around documentation that you see over and over again in open source projects? How do people avoid it or fix it when it happens to them?</li>
<li>With the different projects under the OpenStack umbrella, how much consistency would you expect to see, project-to-project? </li>
<li>As a reader, would you prioritize project docs over overarching docs or vice-versa? Why? </li>
<li>As a project maintainer, which docs would you value more highly, combined solutions docs or docs specific and detailed for your project? Why?</li>
<li>Do you think people want in-person training sessions about how to write OpenStack docs? We're working on a doc boot camp with a day of teaching and a day of doing, what do you think is an important planning part of that? Who specifically would you invite?</li>
<li>How important is "official" to you when it comes to project documentation, such as Python or Django? What editorial/review processes are in place to ensure a doc is considered "official?"</li>
<li>What makes people in a community excited about documentation? Successful outcomes? Camaraderie? Speaking from a point of authority?</li>
</ol>
<p>Thanks all for your input — looking forward to responses and being inspired while I drive cross-country.</p><span class="HOEnZb"><font color="#888888"><p>Anne<br></p></font></span></div>
</blockquote></div><br></div>