<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 2, 2014 at 12:56 PM, Andreas Jaeger <span dir="ltr"><<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" 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="">On 07/01/2014 01:16 AM, Anne Gentle wrote:<br>
><br>
><br>
><br>
> On Mon, Jun 30, 2014 at 4:53 PM, Andreas Jaeger <<a href="mailto:aj@suse.com">aj@suse.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:aj@suse.com">aj@suse.com</a>>> wrote:<br>
><br>
> On 06/30/2014 11:45 PM, Anne Gentle wrote:<br>
> > Hi again all,<br>
> ><br>
> > Thanks to Andreas we have the correct voting access list for the<br>
> > docs-specs repo: <a href="https://review.openstack.org/#/c/103115/" target="_blank">https://review.openstack.org/#/c/103115/</a><br>
> ><br>
> > I wanted to be sure we all understand when you do a spec. This is<br>
> > especially important for docs-specs where you might be better off<br>
> > spending time revising an actual patch rather than continuously<br>
> revising<br>
> > a spec. A spec can be used for:<br>
> > - adding a large portion to an existing deliverable to ensure buy-in<br>
> > from the core doc team<br>
> > - adding an entirely new deliverable to the docs project<br>
> > - any work that requires both content and tooling changes, such as the<br>
> > addition of the API reference site, for sure that work needed a<br>
> blueprint<br>
> > - any large reorganization of a deliverable or set of deliverables<br>
> > - automation work that will need to be designed prior to proposing<br>
> a patch<br>
> > - work that should definitely be discussed at a summit<br>
> ><br>
> > Use bugs for:<br>
> > - known content issues, even if you have to do multiple patches in<br>
> order<br>
> > to close the bug<br>
> > - additions of content that is just plain missing<br>
> > - known errors in the document<br>
> ><br>
> > I want to ensure we balance out the need for up-front approval with<br>
> > "just write it already" -- it's a balancing act and we all should<br>
> start<br>
> > from a point of agreement on these guidelines.<br>
> ><br>
> > Feel free to ask for clarity -<br>
><br>
><br>
> Are there any special rules for approving a blueprint?<br>
><br>
><br>
> I looked through the other team's guidelines, and it's the usual two +2<br>
> votes from -core. I did see that for Oslo, for example, the PTL sent a<br>
> note to the mailing list saying "if you don't -1 this spec by this day<br>
> I'll just approve it myself" so I think that's approach is fine for<br>
> docs-specs.<br>
<br>
<br>
</div></div>Anne, could you document this somewhere, please?<br>
<br>
The repository is alive now, see <a href="https://github.com/openstack/docs-specs" target="_blank">https://github.com/openstack/docs-specs</a><br>
- seems it only misses the ACLs, I'll talk with infra team,<br></blockquote><div><br></div><div>Great! Thanks. Have added to this week's update. </div><div><br></div><div style="font-size:12.727272033691406px;font-family:arial,sans-serif">
I think the ACL for the review team for docs-specs can be as small as:</div><div style="font-size:12.727272033691406px;font-family:arial,sans-serif">Anne Gentle</div><div style="font-size:12.727272033691406px;font-family:arial,sans-serif">
Sean Roberts</div><div style="font-size:12.727272033691406px;font-family:arial,sans-serif">Andreas Jaeger</div><div style="font-size:12.727272033691406px;font-family:arial,sans-serif">Bryan Payne</div><div style="font-size:12.727272033691406px;font-family:arial,sans-serif">
<br></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">or as large as all of docs-core. </span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">I've found that projects are going either way with it. Our setup is a separate team, but we can populate as we need. Any thoughts either way?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Thanks,</span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Anne</span></div>
<div><br></div><div> </div><blockquote class="gmail_quote" 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=""><div class="h5"><br>
Andreas<br>
--<br>
Andreas Jaeger aj@{<a href="http://suse.com" target="_blank">suse.com</a>,<a href="http://opensuse.org" target="_blank">opensuse.org</a>} Twitter/Identica: jaegerandi<br>
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br>
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)<br>
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
</div></div></blockquote></div><br></div></div>