<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 March 2017 at 00:49, Alexandra Settle <span dir="ltr"><<a href="mailto:a.settle@outlook.com" target="_blank">a.settle@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" link="#0563C1" vlink="#954F72" lang="EN-US">
<div class="m_-7861417691566971873WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi team leads,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I’m sure some of you may or may not have seen, I am currently pushing for a ‘documentation review period’ to be officially integrated to the project release schedule. You can see the draft verison for pike
here: <a href="https://releases.openstack.org/pike/schedule.html" target="_blank">https://releases.openstack.<wbr>org/pike/schedule.html</a> If anyone has not seen my email, you can view here:
<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-March/113144.html" target="_blank">
http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>March/113144.html</a> So far, we have mostly positive responses.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">My reason for bringing this up is because we have unfortunately swept up with a lot of bugs post-Ocata release referencing out-of-date content in our guides. Several guides are still referencing Newton content,
or were never updated and are unworkable. These guides include our Installation manuals and reference guides.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From what I can tell, this is a by-product of miscommunication. But I would like to improve on this, and ensure it does not happen again in the future. Here is a link the overview of our release tasks currently:
<a href="https://docs.openstack.org/contributor-guide/release/taskoverview.html" target="_blank">
https://docs.openstack.org/<wbr>contributor-guide/release/<wbr>taskoverview.html</a> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I propose we renew what the specialty leads are doing on our side at release time (especially with the guides that are on the release schedule), and what the cross-project liaisons (CPLs) for docs need to
be doing on their side as there appears to be a little bit of discord between the two currently.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Brian and Maria</span></b><span style="font-size:11.0pt"> – as our most recent release managers, how did pinging the CPLs go before release? Were they responsive?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> </span></p></div></div></blockquote><div><br></div><div>I'm not sure about the status of the other guides, but certainly the Install Guide has proved problematic. I think we should explicitly ask the CPLs from the projects included in the Install Guide to review their chapters. If that had happened we wouldn't have missed the Cellsv2 and Placement content. To be honest, we should have known about those two items prior to the release process starting. Perhaps we need to ask CPLs early in the cycle to send us a list of items they have planned for the next release that they think will require changes to our documentation. We might get some false positives with work that doesn't make it into the release or that doesn't actually belong in our books, but I think that is better than scrambling around after the release trying to fix broken docs.<br><br></div><div>So maybe a two-pronged approach?<br><br></div><div>1. Connect with CPLs early in the cycle to find out what they have in the pipeline that we should keep an eye on. As we get close to release we can check on those items to see where things are at.<br></div><div>2. Make the review process easier for CPLs by sending them a list of chapters/sections they should review prior to release. Perhaps tracked on an etherpad so they can record issues and we can track progress.<br><br></div><div>Brian<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" link="#0563C1" vlink="#954F72" lang="EN-US"><div class="m_-7861417691566971873WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt"><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Team – I want your genuine opinions and suggestions on how we can best improve this process outside of making it official. Do we need to have liaisons that are better integrated in the documentation team?
Perhaps a partnership with a doc person?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">As much as I appreciate the argument that, “If $project don’t update their docs, it’s their problem.” It all comes down to the user, and if the user cannot install $project because it’s not updated, then what
do we have?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Looking forward to your thoughts and opinions,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Alex<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
</div>
</div>
<br>______________________________<wbr>_________________<br>
OpenStack-docs mailing list<br>
<a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-docs</a><br>
<br></blockquote></div><br></div></div>