<div dir="ltr">This sounds great. As I understand it Sean can set up a skeleton for us to work on ops docs (and maybe other things later) with a minimum of initiation energy. Count me in.<div><br></div><div>Chris</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 26, 2018 at 12:42 PM Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Reviving this thread with a fresh start. See below for the original.<br>
<br>
To recap, the ops community is willing to take over some of the operator<br>
documentation that is no longer available due to the loss of documentation team<br>
resources. From discussions, there needs to be some official governance over<br>
this operator owned repo (or repos) so it is recommended that a sig be formed.<br>
The repos can be created in the meantime, but consideration needs to be taken<br>
about naming as by default, the repo name is what is reflected in the<br>
documentation publishing location.<br>
<br>
SIG Formation<br>
-------------<br>
There were a couple suggestions on naming and focus for this sig, but I would<br>
like to make a slightly different proposal. I would actually like to see a<br>
sig-operator group formed. We have repos for operator tools and other useful<br>
things and we have a mix of operators, vendors, and others that work together<br>
on things like the ops meetup. I think it would make sense to make this into an<br>
official SIG that could have a broader scope than just documentation.<br>
<br>
Docs Repos<br>
----------<br>
Doug made a good suggestion that we may want these things published under<br>
something like <a href="http://docs.openstack.org/operations-guide" rel="noreferrer" target="_blank">docs.openstack.org/operations-guide</a>. So based on this, I think<br>
for now at least we should create an opestack/operations-guide repo that will<br>
end up being owned by this SIG. I would expect most documentation generated or<br>
owned by this group would just be located somewhere under that repo, but if the<br>
need arises we can add additional repos.<br>
<br>
There are other ops repos out there right now. I would expect the ownership of<br>
those to move under this sig as well, but that is a seperate and less pressing<br>
concern at this point.<br>
<br>
Bug Tracking<br>
------------<br>
There should be some way to track tasks and needs for this documentation and<br>
any other repos that are moved under this sig. Since it is the currently<br>
planned direction for all OpenStack projects (or at least there is a vocal<br>
desire for it to be) I think a Storyboard project should be created for this<br>
SIG's activities.<br>
<br>
Plan<br>
----<br>
So to recap above, I would propose the following actions be taken:<br>
<br>
1. Create sig-operators as a group to manage operator efforts at least related<br>
   to what needs to be done in repos.<br>
2. Create an openstack/operations-guide repo to be the new home of the<br>
   operations documentation.<br>
3. Create a new StoryBoard project to help track work in these repos<br>
x. Document all this.<br>
9. Profit!<br>
<br>
I'm willing to work through the steps to get these things set up. Please give<br>
feedback if this proposed plan makes sense or if there is anything different<br>
that would be preferred.<br>
<br>
Thanks,<br>
Sean<br>
<br>
On Wed, May 23, 2018 at 06:38:32PM -0700, Chris Morgan wrote:<br>
> Hello Everyone,<br>
> <br>
> In the Ops Community documentation working session today in Vancouver, we<br>
> made some really good progress (etherpad here:<br>
> <a href="https://etherpad.openstack.org/p/YVR-Ops-Community-Docs" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/YVR-Ops-Community-Docs</a> but not all of the<br>
> good stuff is yet written down).<br>
> <br>
> In short, we're going to course correct on maintaining the Operators Guide,<br>
> the HA Guide and Architecture Guide, not edit-in-place via the wiki and<br>
> instead try still maintaining them as code, but with a different, new set<br>
> of owners, possibly in a new Ops-focused repo. There was a strong consensus<br>
> that a) code workflow >> wiki workflow and that b) openstack core docs<br>
> tools are just fine.<br>
> <br>
> There is a lot still to be decided on how where and when, but we do have an<br>
> offer of a rewrite of the HA Guide, as long as the changes will be allowed<br>
> to actually land, so we expect to actually start showing some progress.<br>
> <br>
> At the end of the session, people wanted to know how to follow along as<br>
> various people work out how to do this... and so for now that place is this<br>
> very email thread. The idea is if the code for those documents goes to live<br>
> in a different repo, or if new contributors turn up, or if a new version we<br>
> will announce/discuss it here until such time as we have a better home for<br>
> this initiative.<br>
> <br>
> Cheers<br>
> <br>
> Chris<br>
> <br>
> -- <br>
> Chris Morgan <<a href="mailto:mihalis68@gmail.com" target="_blank">mihalis68@gmail.com</a>><br>
<br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Chris Morgan <<a href="mailto:mihalis68@gmail.com" target="_blank">mihalis68@gmail.com</a>></div>