Open Stack

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?

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

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