<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 30, 2014 at 4:53 PM, Andreas Jaeger <span dir="ltr"><<a href="mailto:aj@suse.com" target="_blank">aj@suse.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><div>On 06/30/2014 11:45 PM, Anne Gentle wrote:<br>
> Hi again all,<br>
><br>
> Thanks to Andreas we have the correct voting access list for the<br>
> docs-specs repo: <a href="https://review.openstack.org/#/c/103115/" target="_blank">https://review.openstack.org/#/c/103115/</a><br>
><br>
> I wanted to be sure we all understand when you do a spec. This is<br>
> especially important for docs-specs where you might be better off<br>
> spending time revising an actual patch rather than continuously revising<br>
> a spec. A spec can be used for:<br>
> - adding a large portion to an existing deliverable to ensure buy-in<br>
> from the core doc team<br>
> - adding an entirely new deliverable to the docs project<br>
> - any work that requires both content and tooling changes, such as the<br>
> addition of the API reference site, for sure that work needed a blueprint<br>
> - any large reorganization of a deliverable or set of deliverables<br>
> - automation work that will need to be designed prior to proposing a patch<br>
> - work that should definitely be discussed at a summit<br>
><br>
> Use bugs for:<br>
> - known content issues, even if you have to do multiple patches in order<br>
> to close the bug<br>
> - additions of content that is just plain missing<br>
> - known errors in the document<br>
><br>
> I want to ensure we balance out the need for up-front approval with<br>
> "just write it already" -- it's a balancing act and we all should start<br>
> from a point of agreement on these guidelines.<br>
><br>
> Feel free to ask for clarity -<br>
<br>
<br>
</div></div>Are there any special rules for approving a blueprint?<br></blockquote><div><br></div><div>I looked through the other team's guidelines, and it's the usual two +2 votes from -core. I did see that for Oslo, for example, the PTL sent a note to the mailing list saying "if you don't -1 this spec by this day I'll just approve it myself" so I think that's approach is fine for docs-specs. </div>
<div> </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>
we have a few blueprints already active for Juno. Should those now moved<br>
to the new repo (once it life)?<br></blockquote><div><br></div><div>We'll always have blueprints in Launchpad, and if those already have wiki pages and are approved, I don't need to see them in the docs-specs repo. </div>
<div><br></div><div>These three blueprints I believe still need discussion and specification:</div><div>* <a href="https://blueprints.launchpad.net/openstack-manuals/+spec/python-client-docs-for-app-devs" target="_blank">https://blueprints.launchpad.net/openstack-manuals/+spec/python-client-docs-for-app-devs</a> I requested more discussion on exactly what work should be done.<br>
</div><div><br></div><div>* <a href="https://blueprints.launchpad.net/openstack-manuals/+spec/redesign-docs-site" target="_blank">https://blueprints.launchpad.net/openstack-manuals/+spec/redesign-docs-site</a> I plan to write a spec this once we get a web design plan laid out in more detail.<br>
</div><div><br></div><div>* <a href="https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates" target="_blank">https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates</a> We've discussed a lot on the ML but it doesn't have a linked wiki page and could use further description and decisions.<br>
</div><div><br></div><div>The "improve-ha-guide" and "redocument-xen" blueprints don't have clear owners, but would likely need a spec before proceeding.</div><div><br></div><div>Sean has some training blueprints he wants to propose, and hopefully the guidelines will help.</div>
<div><br></div><div>That's a run-through of the blueprints marked higher than Low. For ones marked low, I'll take a closer look tomorrow.</div><div>Good questions - </div><div>Anne</div><div> </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">
<div><div><br>
Andreas<br>
--<br>
Andreas Jaeger aj@{<a href="http://suse.com" target="_blank">suse.com</a>,<a href="http://opensuse.org" target="_blank">opensuse.org</a>} Twitter/Identica: jaegerandi<br>
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br>
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)<br>
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
</div></div></blockquote></div><br></div></div>