Open Stack

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/7cc5e277/attachment-0001.html>