Open Stack

On 07/02/2014 08:21 PM, Anne Gentle wrote:
> 
> 
> 
> On Wed, Jul 2, 2014 at 12:56 PM, Andreas Jaeger <aj at suse.com
> <mailto:aj at suse.com>> wrote:
> 
>     On 07/01/2014 01:16 AM, Anne Gentle wrote:
>     >
>     >
>     >
>     > On Mon, Jun 30, 2014 at 4:53 PM, Andreas Jaeger <aj at suse.com
>     <mailto:aj at suse.com>
>     > <mailto:aj at suse.com <mailto: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.
> 
> 
>     Anne, could you document this somewhere, please?
> 
>     The repository is alive now, see https://github.com/openstack/docs-specs
>      - seems it only misses the ACLs, I'll talk with infra team,
> 
> 
> Great! Thanks. Have added to this week's update. 
> 
> I think the ACL for the review team for docs-specs can be as small as:
> Anne Gentle
> Sean Roberts
> Andreas Jaeger
> Bryan Payne
> 
> or as large as all of docs-core. 

I don't have a preference - but think it's good to have people from
different areas as you proposed in,

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