<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10pt"><div class="" style=""><span class="" style="">We created these steps for creating a spec/blueprint</span></div><div style="background-color: transparent;" class=""><span class="" style=""><a href="https://wiki.openstack.org/wiki/Training-guides#Create_a_Blueprint" class="" style="">https://wiki.openstack.org/wiki/Training-guides#Create_a_Blueprint</a><br class="" style=""></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">With the addition of the why to blueprint verse bug above, it still looks good.</div><div class="" style=""></div><div class="" style=""> </div><div class="" style=""><div class="" style=""><b class=""
style=""><br class="" style=""></b></div><div class="" style="font-family:arial, helvetica, clean, sans-serif;font-weight:bold;"><b class="" style="">Sean Roberts</b></div><div class="" style="">Infrastructure Strategy, Yahoo</div><div class="" style=""><span class="" style=""><a rel="nofollow" target="_blank" href="mailto:seanrob@yahoo-inc.com" class="" style="">seanrob@yahoo-inc.com</a></span></div><div class="" style="">(925) 980-4729</div></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 10pt;" class=""> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;" class=""> <div dir="ltr" class="" style=""> <font size="2" face="Arial" class="" style=""> On Monday, June 30, 2014 4:17 PM, Anne Gentle <anne@openstack.org> wrote:<br
class="" style=""> </font> </div> <br class="" style=""><br class="" style=""> <div class="" style=""><div id="yiv4508837540" class="" style=""><div class="" style=""><div dir="ltr" class="" style=""><br clear="none" class="" style=""><div class="" style=""><br clear="none" class="" style=""><br clear="none" class="" style=""><div class="" style="">On Mon, Jun 30, 2014 at 4:53 PM, Andreas Jaeger <span dir="ltr" class="" style=""><<a rel="nofollow" shape="rect" ymailto="mailto:aj@suse.com" target="_blank" href="mailto:aj@suse.com" class="" style="">aj@suse.com</a>></span> wrote:<br clear="none" class="" style="">
<blockquote class="" 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="" style=""><div class="" style="">On 06/30/2014 11:45 PM, Anne Gentle wrote:<br clear="none" class="" style="">
> Hi again all,<br clear="none" class="" style="">
><br clear="none" class="" style="">
> Thanks to Andreas we have the correct voting access list for the<br clear="none" class="" style="">
> docs-specs repo: <a rel="nofollow" shape="rect" target="_blank" href="https://review.openstack.org/#/c/103115/" class="" style="">https://review.openstack.org/#/c/103115/</a><br clear="none" class="" style="">
><br clear="none" class="" style="">
> I wanted to be sure we all understand when you do a spec. This is<br clear="none" class="" style="">
> especially important for docs-specs where you might be better off<br clear="none" class="" style="">
> spending time revising an actual patch rather than continuously revising<br clear="none" class="" style="">
> a spec. A spec can be used for:<br clear="none" class="" style="">
> - adding a large portion to an existing deliverable to ensure buy-in<br clear="none" class="" style="">
> from the core doc team<br clear="none" class="" style="">
> - adding an entirely new deliverable to the docs project<br clear="none" class="" style="">
> - any work that requires both content and tooling changes, such as the<br clear="none" class="" style="">
> addition of the API reference site, for sure that work needed a blueprint<br clear="none" class="" style="">
> - any large reorganization of a deliverable or set of deliverables<br clear="none" class="" style="">
> - automation work that will need to be designed prior to proposing a patch<br clear="none" class="" style="">
> - work that should definitely be discussed at a summit<br clear="none" class="" style="">
><br clear="none" class="" style="">
> Use bugs for:<br clear="none" class="" style="">
> - known content issues, even if you have to do multiple patches in order<br clear="none" class="" style="">
> to close the bug<br clear="none" class="" style="">
> - additions of content that is just plain missing<br clear="none" class="" style="">
> - known errors in the document<br clear="none" class="" style="">
><br clear="none" class="" style="">
> I want to ensure we balance out the need for up-front approval with<br clear="none" class="" style="">
> "just write it already" -- it's a balancing act and we all should start<br clear="none" class="" style="">
> from a point of agreement on these guidelines.<br clear="none" class="" style="">
><br clear="none" class="" style="">
> Feel free to ask for clarity -<br clear="none" class="" style="">
<br clear="none" class="" style="">
<br clear="none" class="" style="">
</div></div>Are there any special rules for approving a blueprint?<br clear="none" class="" style=""></blockquote><div class="" style=""><br clear="none" class="" style=""></div><div class="" style="">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 class="" style=""> </div><blockquote class="" 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 clear="none" class="" style="">
we have a few blueprints already active for Juno. Should those now moved<br clear="none" class="" style="">
to the new repo (once it life)?<br clear="none" class="" style=""></blockquote><div class="" style=""><br clear="none" class="" style=""></div><div class="" style="">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 class="" style=""><br clear="none" class="" style=""></div><div class="" style="">These three blueprints I believe still need discussion and specification:</div><div class="" style="">* <a rel="nofollow" shape="rect" target="_blank" href="https://blueprints.launchpad.net/openstack-manuals/+spec/python-client-docs-for-app-devs" class="" style="">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 clear="none" class="" style="">
</div><div class="" style=""><br clear="none" class="" style=""></div><div class="" style="">* <a rel="nofollow" shape="rect" target="_blank" href="https://blueprints.launchpad.net/openstack-manuals/+spec/redesign-docs-site" class="" style="">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 clear="none" class="" style="">
</div><div class="" style=""><br clear="none" class="" style=""></div><div class="" style="">* <a rel="nofollow" shape="rect" target="_blank" href="https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates" class="" style="">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 clear="none" class="" style="">
</div><div class="" style=""><br clear="none" class="" style=""></div><div class="" style="">The "improve-ha-guide" and "redocument-xen" blueprints don't have clear owners, but would likely need a spec before proceeding.</div><div class="" style=""><br clear="none" class="" style=""></div><div class="" style="">Sean has some training blueprints he wants to propose, and hopefully the guidelines will help.</div>
<div class="" style=""><br clear="none" class="" style=""></div><div class="" style="">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 class="" style="">Good questions - </div><div class="" id="yiv4508837540yqtfd32134" style=""><div class="" style="">Anne</div><div class="" style=""> </div><blockquote class="" 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="" style=""><div class="" style=""><br clear="none" class="" style="">
Andreas<br clear="none" class="" style="">
--<br clear="none" class="" style="">
Andreas Jaeger aj@{<a rel="nofollow" shape="rect" target="_blank" href="http://suse.com/" class="" style="">suse.com</a>,<a rel="nofollow" shape="rect" target="_blank" href="http://opensuse.org/" class="" style="">opensuse.org</a>} Twitter/Identica: jaegerandi<br clear="none" class="" style="">
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br clear="none" class="" style="">
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)<br clear="none" class="" style="">
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br clear="none" class="" style="">
</div></div></blockquote></div></div><div class="" id="yiv4508837540yqtfd63197" style=""><br clear="none" class="" style=""></div></div></div></div></div><br class="" style=""><br class="" style=""></div> </div> </div> </div> </div></body></html>