Open Stack

Hi folks:

I'm excited to see the SIG concept proposal being introduced in OpenStack
-- and while I realize that it still seems to be in the discussion phase of
"we know this is potentially useful, and seems to be effective in other
communities, but what should our goals and expectations be?" -- I thought
it might be useful for those involved to know why I am interested and what
I would hope for as a potential organizer / wrangler.

I'm hoping this mail can (a) help the meta-SIG move along by having a
useful potential "use case"; (b) if appropriate, open the door for me to
organize or be a guinea-pig of sorts as an organizer of one of the first
SIGs, and in the process also provide feedback or help back to the meta sig
around the more meta-things. (Information that would be useful to a SIG
organizer, etc. Meta!) (And apologies if my case is way off here from what
folks were thinking; I did read all the various notes and etherpads thus
far, but misinterpretation is always possible :D)

As background for those who don't know me -- I'm the (official title)
Community Architect for Ansible (and yes, employed by Red Hat). In addition
to traditional community things (clearing out bottlenecks in github,
empowering contributors to get stuff done and removing roadblocks if
needed, making sure humans have swag, etc.) -- I also spend some amount of
my time working with adjacent communities, particularly OpenStack. I also
organized the Ansible open source day at the last Summit (thank you for the
opportunity!). That work is usually less in the form of "actual commits"
and more in the form of cat-herding, connecting humans, etc. Writing the
occasional really long email. (Sorry... :D)

Which brings me to, for lack of a better word, my "user story" for SIGs --
that is, what I think it could mean for me as a potential organizer (and
really, Ansible, as it relates to OpenStack), why it would be useful, etc:

1:  I've always wished for an obvious, official-ish space for
Ansible-related information inside of OpenStack. There are a multitude of
projects (openstack-ansible, kolla, ARA, potentially triple-o,
openstack-infra, bifrost, zuul, etc.) making use of Ansible in OpenStack;
plus openstack-related work in Ansible (modules) that are useful to point
out to end-users, plus many operators and end-users with Ansible-y ways of
deploying, maintaining, upgrading, managing, operating, and consuming
OpenStack. There's never been a unified space in OpenStack with all the
Ansible-related information or pointers an end user or operator might be
searching for; there are plenty of places to land, and plenty of friendly
folks willing to point people in the right direction, but a shorter, less
potentially-confusing path would be awesome.

But it's never quite been a "needs an OpenStack project of its own" type of
a problem.

Having a source of "unopinionated," all-Ansible-related information inside
of OpenStack that can be collectively maintained by OpenStack developers
and users, that clearly states the various Ansible-y OpenStack projects,
resources, and associated tools (modules, playbooks, etc.) for all
potential users who may already have an affinity for Ansible would be (I
believe, anyway) incredibly useful for that audience. And I think would be
the minimum viable output I would hope for in a SIG effort; I think it
would also be the logical doorway for finding new users and contributors to
collaborate with and have better user/developer feedback loops around
Ansible + OpenStack in general. Since communicating across that many groups
can be daunting, particularly for new folks.

2: Given the number of projects with varying degrees of Ansible usage
inside of OpenStack -- as well as a collection of folks hailing from many
of those teams who together maintain the OpenStack modules in Ansible's
community, and plenty of operators and end users using Ansible to deploy /
manage / consume OpenStack clouds -- well, there are plenty of
opportunities for collaboration across these groups. This is the place
where having a SIG could be really really useful and productive.

* More coordinated collaboration around reusable Ansible components (roles,
playbooks, etc.) for Ansible-y projects in OpenStack, as well as for end
users (frequent OpenStack tasks, etc.)
* Growing the base of contributors and expertise around the existing and
future OpenStack modules in Ansible (and the underlying shade library).
(This is a crew of a few folks right now -- 5 or 6 at most, most of whom
already have plennnnnnnnnty to do.)
* Have a general space (irc, mailing list, whatever is most appropriate)
where developers and operators / end users can ask a broad pool of
Ansible/OpenStack knowledgeable folks questions -- and know that it's the
most welcoming space for those questions (vs. -devel and cross-posting to 6
or seven groups, or not all devel folks being on the operators' list,
etc.). Also an opportunity to help everyone build best practices knowledge.
* While I know that at some point in the future, the -infra discussion
around "starting to test certain types changes to Ansible itself inside of
OpenStack-infra / Zuul" (3rd party dependency type things) may become a
reality -- having a unified space to discuss those changes, and/or wishes
that would help OpenStack in general, would be useful.

***

An Ansible SIG, in my head, would probably look like the following:

* Seeded with reps / members from the various ansible-related efforts,
hopefully a handful of Ansible-loving operators, plus anyone else who cares
to join
* Communication via SIG mailing list with an [ansible] tag; not clear on if
/ when to also bring in -devel or operators / users / etc. mailing lists or
if folks would be expected to branch out to other lists as necessary
* IRC meetings likely in the beginning, which may taper off once decisions
about scope of the group and potential work are resolved (people have
plenty of meetings as it is, really :D)
* Maintain an IRC presence in a channel (of unknown name) for questions /
collective discussion / etc.

Initial work would probably look like:
* Create a space outlining what we do and who we are, how to join in, and
any participation-related info (meetings, lists, etc.) and create those
participation/collaboration spaces. ("what we do and who we are" might
actually be a prerequisite to obtaining a SIG space to work in, in which
case, that's when I'd cobble that together.)
* Detailing Ansible-related information (as described above) in the
appropriate OpenStack space (whether it's docs, wiki, project space similar
to regular openstack projects);
* Determine if / what any further work we might do will be --- even if it's
as simple as "Robyn will occasionally make sure you're all aware of
particular things going on in Ansible that might affect all of you," or
similar unified-but-not-quite-all-openstack-devel worthy types of
communications. But there are plenty of possibilities, certainly.
* And generally: ongoing commitment to being around in the right
collaboration places to help folks out with Ansible + OpenStack questions
if needed.
* Also: Tell the world the sig exists in various channels and ways, and to
come join in the fun. :D

This assumes that after my initial "hey, y'all, maybe we should do this"
outreach to the likely individuals... they agree it's worth giving it a
shot. :)

***

All that said -- we have, in Ansible, *also* introduced a similar concept
-- albeit called "working groups" in Ansible-land. Ansible, being a younger
project, has less governance, and (while yes, bikeshedding exists,
including around "what does a working group do" and requirements) thus for
us, right now, having a Working Group consists of:

* Request a working group by providing the name, names of at least 2 folks
wanting to participate, and the description of what you're doing, which
gets you wiki space, an IRC channel + a bot, and a landing page in the
ansible/community repo on github.)
* Fill out the wiki with any additional information (what you're working
on, if/when you have meetings and if there's an agenda, any ideas or goals)
so folks can find it and participate. (And referring folks to the Working
Group space in the appropriate developer or user documentation if
necessary.)

(Example: https://github.com/ansible/community/tree/master/group-windows is
the Windows Working Group, and has basic collaboration info, points to wiki
space for collaboration, etc.)

Now that we have a few active Working Groups -- we expect in a few months,
we'll be able to better identify what the best practices or expectations
should be for Working Groups (if any) -- particularly if some seem to be
more productive than others. It's a bit of an experiment, and like
OpenStack, we're mostly taking cues from how well this has worked in other
communities -- but we're not setting anything in stone just yet as far as
requirements or expectations go.

One of the items I have been asked about is whether or not I will be
starting an OpenStack Working Group in Ansible. :) And honestly, I can see
it as having more or less the same types of output and purpose as an
Ansible SIG in OpenStack... which I do plan to create, even if it's "this
Working Group is basically the Ansible SIG in OpenStack, here are the
basics, go look over there for more info and how to participate!" (I do
think that OpenStack is a better space for this particular set of stuff --
but if it turns this isn't the right stuff for a SIG in openstack, then
Ansible it is :D)

While some of that is specific to my own case, and I've mostly provided
Ansible's approach to the concept in the interest of "example of how this
is working in other communities" -- I would like to point out that if the
SIG concept is open to cross-community types of SIGs, it might be useful to
actually have OpenStack folks (or whomever the SIG leadership is) have at
least minimal / introductory contact with that other open source
community's members or leadership so that cross-community pointers or
general understanding is somewhat coordinated, determine if any ongoing
communication or "report-out" types of things should be cross-posted to
both communities, and generally making sure that folks in the community
adjacent to OpenStack feel like their community or objectives are being
fairly represented. And if nothing else -- ensuring that OpenStack's use of
the adjacent community's trademark is welcomed / approved / at least not
frowned upon without prior clearance :D, particularly since some
communities might believe that it represents some form of endorsement or
official-ness. (I may also be overly paranoid here and this might be
entirely unnecessary bureaucracy that prevents people from just getting
stuff done. :D)

Sorry for the long mail (I am only semi-famous for this) -- but thought
having some of this might help the folks taking the lead in meta-sig-land
have a concrete example in mind of what someone might want to do. :)

Cheers,

-r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20170718/7719d65d/attachment-0001.html>