[Openstack-operators] Ops Community Documentation - first anchor point

Doug Hellmann doug at doughellmann.com
Thu May 24 14:07:10 UTC 2018


Excerpts from Doug Hellmann's message of 2018-05-23 22:58:40 -0700:
> Excerpts from Melvin Hillsman's message of 2018-05-23 22:26:02 -0700:
> > Great to see this moving. I have some questions/concerns based on your
> > statement Doug about docs.openstack.org publishing and do not want to
> > detour the conversation but ask for feedback. Currently there are a number
> 
> I'm just unclear on that, but don't consider it a blocker. We will sort
> out whatever governance or policy change is needed to let this move
> forward.

When I talked with Petr about it, he pointed to the Security SIG
and Security Guide as a parallel precedent for this. IIRC, yesterday
Adam mentioned that the Self-Healing SIG was also going to be
managing some documentation, so we have two examples.

Looking at https://governance.openstack.org/sigs/, I don't see
another existing SIG that it would make sense to join, so, I think
to deal with the publishing rights we would want set up a SIG for
something like "Operator Documentation," which gives you some
flexibility on exactly what content is managed.

I know you wanted to avoid lots of governance overhead, so I want
to just mention that establishing a SIG is meant to be a painless
and light-weight way to declare that a group of interested people
exists so that others can find them and participate in the work
[1]. It shouldn't take much effort to do the setup, and any ongoing
communication is something you would presumably by doing anyway
among a group of people trying to collaborate on a project like
this.

Let me know if you have any questions or concerns about the process.

Doug

[1] https://governance.openstack.org/sigs/#process-to-create-a-sig

> 
> > of repositories under osops-
> > 
> > https://github.com/openstack-infra/project-config/blob/master/gerrit/projects.yaml#L5673-L5703
> > 
> > Generally active:
> > osops-tools-contrib
> > osops-tools-generic
> > osops-tools-monitoring
> > 
> > 
> > Probably dead:
> > osops-tools-logging
> > osops-coda
> > osops-example-configs
> > 
> > Because you are more familiar with how things work, is there a way to
> > consolidate these vs coming up with another repo like osops-docs or
> > whatever in this case? And second, is there already governance clearance to
> > publish based on the following - https://launchpad.net/osops - which is
> > where these repos originated.
> 
> I don't really know what any of those things are, or whether it
> makes sense to put this new content there. I assumed we would make
> a repo with a name like "operations-guide", but that's up to Chris
> and John.  If they think reusing an existing repository makes sense,
> that would be OK with me, but it's cheap and easy to set up a new
> one, too.
> 
> My main concern is that we remove the road blocks, now that we have
> people interested in contributing to this documentation.
> 
> > 
> > On Wed, May 23, 2018 at 9:56 PM, Frank Kloeker <eumel at arcor.de> wrote:
> > 
> > > Hi Chris,
> > >
> > > thanks for summarize our session today in Vancouver. As I18n PTL and one
> > > of the Docs Core I put Petr in Cc. He is currently Docs PTL, but
> > > unfortunatelly not on-site.
> > > I couldn't also not get the full history of the story and that's also not
> > > the idea to starting finger pointing. As usualy we moving forward and there
> > > are some interesting things to know what happened.
> > > First of all: There are no "Docs-Team" anymore. If you look at [1] there
> > > are mostly part-time contributors like me or people are more involved in
> > > other projects and therefore busy. Because of that, the responsibility of
> > > documentation content are moved completely to the project teams. Each repo
> > > has a user guide, admin guide, deployment guide, and so on. The small
> > > Documentation Team provides only tooling and give advices how to write and
> > > publish a document. So it's up to you to re-use the old repo on [2] or
> > > setup a new one. I would recommend to use the best of both worlds. There
> > > are a very good toolset in place for testing and publishing documents.
> > > There are also various text editors for rst extensions available, like in
> > > vim, notepad++ or also online services. I understand the concerns and when
> > > people are sad because their patches are ignored for months. But it's
> > > alltime a question of responsibilty and how can spend people time.
> > > I would be available for help. As I18n PTL I could imagine that a
> > > OpenStack Operations Guide is available in different languages and portable
> > > in different formats like in Sphinx. For us as translation team it's a good
> > > possibility to get feedback about the quality and to understand the
> > > requirements, also for other documents.
> > > So let's move on.
> > >
> > > kind regards
> > >
> > > Frank
> > >
> > > [1] https://review.openstack.org/#/admin/groups/30,members
> > > [2] https://github.com/openstack/operations-guide
> > >
> > >
> > > Am 2018-05-24 03:38, schrieb Chris Morgan:
> > >
> > >> Hello Everyone,
> > >>
> > >> In the Ops Community documentation working session today in Vancouver,
> > >> we made some really good progress (etherpad here:
> > >> https://etherpad.openstack.org/p/YVR-Ops-Community-Docs but not all of
> > >> the good stuff is yet written down).
> > >>
> > >> In short, we're going to course correct on maintaining the Operators
> > >> Guide, the HA Guide and Architecture Guide, not edit-in-place via the
> > >> wiki and instead try still maintaining them as code, but with a
> > >> different, new set of owners, possibly in a new Ops-focused repo.
> > >> There was a strong consensus that a) code workflow >> wiki workflow
> > >> and that b) openstack core docs tools are just fine.
> > >>
> > >> There is a lot still to be decided on how where and when, but we do
> > >> have an offer of a rewrite of the HA Guide, as long as the changes
> > >> will be allowed to actually land, so we expect to actually start
> > >> showing some progress.
> > >>
> > >> At the end of the session, people wanted to know how to follow along
> > >> as various people work out how to do this... and so for now that place
> > >> is this very email thread. The idea is if the code for those documents
> > >> goes to live in a different repo, or if new contributors turn up, or
> > >> if a new version we will announce/discuss it here until such time as
> > >> we have a better home for this initiative.
> > >>
> > >> Cheers
> > >>
> > >> Chris
> > >>
> > >> --
> > >> Chris Morgan <mihalis68 at gmail.com>
> > >> _______________________________________________
> > >> OpenStack-operators mailing list
> > >> OpenStack-operators at lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > >>
> > >
> > >
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > OpenStack-operators at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > >
> > 



More information about the OpenStack-operators mailing list