<div dir="ltr">Hi again all, <div><br></div><div>Thanks to Andreas we have the correct voting access list for the docs-specs repo: <a href="https://review.openstack.org/#/c/103115/">https://review.openstack.org/#/c/103115/</a> </div>
<div><br></div><div>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:</div>
<div>- adding a large portion to an existing deliverable to ensure buy-in from the core doc team</div><div>- adding an entirely new deliverable to the docs project</div><div>- 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</div>
<div>- any large reorganization of a deliverable or set of deliverables</div><div>- automation work that will need to be designed prior to proposing a patch</div><div>- work that should definitely be discussed at a summit</div>
<div><br></div><div>Use bugs for:</div><div>- known content issues, even if you have to do multiple patches in order to close the bug</div><div>- additions of content that is just plain missing </div><div>- known errors in the document</div>
<div><br></div><div>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. </div>
<div><br></div><div>Feel free to ask for clarity -</div><div>Thanks,</div><div>Anne</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 8:25 AM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Fri, Jun 27, 2014 at 7:59 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 06/27/2014 02:40 PM, Anne Gentle wrote:<br>
><br>
><br>
><br>
> On Wed, Jun 25, 2014 at 3:22 PM, Sean Roberts <<a href="mailto:seanrob@yahoo-inc.com" target="_blank">seanrob@yahoo-inc.com</a><br>
</div><div>> <mailto:<a href="mailto:seanrob@yahoo-inc.com" target="_blank">seanrob@yahoo-inc.com</a>>> wrote:<br>
><br>
> Having many sub-directories follows the docs layout because of the<br>
> different repos. If we go that way then we would need to treat each<br>
> project directory separate with their own release directories like<br>
> /doc-spec/training-guides/juno<br>
><br>
> The drawback will be that this makes finding approved specs<br>
> difficult. The other projects are using the single /specs directory<br>
> with a flat naming scheme like ml2-dell-afc-mech-driver.rst.<br>
><br>
> For specs that overlay projects like install-guides and<br>
> training-guides, it will be confusing which, what, where. Because of<br>
> this I vote for this structure<br>
><br>
> doc-spec -<br>
> specs -<br>
> juno - (all docs program juno cycle RST reside here)<br>
> tests -<br>
> doc -<br>
><br>
><br>
><br>
> Yep, looks like that's the accepted structure.<br>
><br>
> Here's the starting openstack-infra/config patch:<br>
><br>
> <a href="https://review.openstack.org/103115" target="_blank">https://review.openstack.org/103115</a><br>
><br>
> and I'll populate the repo with this repo:<br>
><br>
> <a href="https://github.com/annegentle/docs-specs" target="_blank">https://github.com/annegentle/docs-specs</a><br>
<br>
<br>
</div>That repo contains many references to Glance - do you want to update it<br>
first or do this later?<br></blockquote><div><br></div></div></div><div>Updating now. </div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><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></div><br></div></div>
</blockquote></div><br></div>