Open Stack

We created these steps for creating a spec/blueprint
https://wiki.openstack.org/wiki/Training-guides#Create_a_Blueprint

With the addition of the why to blueprint verse bug above, it still looks good.
 


Sean Roberts
Infrastructure Strategy, Yahoo
seanrob at yahoo-inc.com
(925) 980-4729


On Monday, June 30, 2014 4:17 PM, Anne Gentle <anne at openstack.org> wrote:
 







On Mon, Jun 30, 2014 at 4:53 PM, Andreas Jaeger <aj at suse.com> wrote:

On 06/30/2014 11:45 PM, Anne Gentle wrote:
>> Hi again all,
>>
>> Thanks to Andreas we have the correct voting access list for the
>> docs-specs repo: https://review.openstack.org/#/c/103115/
>>
>> I wanted to be sure we all understand when you do a spec. This is
>> especially important for docs-specs where you might be better off
>> spending time revising an actual patch rather than continuously revising
>> a spec. A spec can be used for:
>> - adding a large portion to an existing deliverable to ensure buy-in
>> from the core doc team
>> - adding an entirely new deliverable to the docs project
>> - any work that requires both content and tooling changes, such as the
>> addition of the API reference site, for sure that work needed a blueprint
>> - any large reorganization of a deliverable or set of deliverables
>> - automation work that will need to be designed prior to proposing a patch
>> - work that should definitely be discussed at a summit
>>
>> Use bugs for:
>> - known content issues, even if you have to do multiple patches in order
>> to close the bug
>> - additions of content that is just plain missing
>> - known errors in the document
>>
>> I want to ensure we balance out the need for up-front approval with
>> "just write it already" -- it's a balancing act and we all should start
>> from a point of agreement on these guidelines.
>>
>> Feel free to ask for clarity -
>
>
>Are there any special rules for approving a blueprint?
>

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. 
 

>we have a few blueprints already active for Juno. Should those now moved
>to the new repo (once it life)?
>

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. 

These three blueprints I believe still need discussion and specification:
* https://blueprints.launchpad.net/openstack-manuals/+spec/python-client-docs-for-app-devs I requested more discussion on exactly what work should be done.


* https://blueprints.launchpad.net/openstack-manuals/+spec/redesign-docs-site I plan to write a spec this once we get a web design plan laid out in more detail.


* https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates We've discussed a lot on the ML but it doesn't have a linked wiki page and could use further description and decisions.


The "improve-ha-guide" and "redocument-xen" blueprints don't have clear owners, but would likely need a spec before proceeding.

Sean has some training blueprints he wants to propose, and hopefully the guidelines will help.

That's a run-through of the blueprints marked higher than Low. For ones marked low, I'll take a closer look tomorrow.
Good questions - 
Anne
 

>Andreas
>--
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140630/007d52d8/attachment.html>