Open Stack

I think a great model we have in general as a community is if people show
up to do the work, it is not something crazy, get out of their way; at
least that is how I think of it. I apologize if there is any perception
opposed to my previous statement by me bringing up the other repos. I tried
to be clear in wanting to get feedback from Doug in hope that as we move
forward in general, what are some thoughts on that front to ensure we
continue to remove roadblocks if any exist in parallel to great work, like
what Chris is driving here. On that front, please do what works best for
those doing the work.

On Thu, May 24, 2018 at 7:26 AM, Jonathan D. Proulx <jon at csail.mit.edu>
wrote:

> On Thu, May 24, 2018 at 07:07:10AM -0700, Doug Hellmann wrote:
>
> :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.
>
> Yeah I can see SIG as a useful structure too.  I'm just more familiar
> with UC "teams" because of my personal history.
>
> I do thing SIG -vs- team would impace repo naming, and I'm still going
> over creation doc, so I'll let this simmer here at least until YVR lunch
> time to see if there's consensus or cotroversy in the potential
> contributer community.  Lacking either I think I will default to
> SIG-ops-docs.
>
> Thanks,
> -Jon
>
> :
> :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
> :> > >
> :> >
> :
> :_______________________________________________
> :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
>



-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180524/3b098c95/attachment.html>