<div dir="ltr">Hi folks:<div><br></div><div>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. </div><div><br></div><div>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)</div><div><br></div><div>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)</div><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>But it's never quite been a "needs an OpenStack project of its own" type of a problem. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>* 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.)</div><div>* 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.)</div><div>* 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.</div><div>* 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. <br></div><div><br></div><div>***</div><div><br></div><div>An Ansible SIG, in my head, would probably look like the following:</div><div><br></div><div>* Seeded with reps / members from the various ansible-related efforts, hopefully a handful of Ansible-loving operators, plus anyone else who cares to join</div><div>* 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</div><div>* 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)</div><div>* Maintain an IRC presence in a channel (of unknown name) for questions / collective discussion / etc. </div><div><br></div><div>Initial work would probably look like:</div><div>* 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.)</div><div>* Detailing Ansible-related information (as described above) in the appropriate OpenStack space (whether it's docs, wiki, project space similar to regular openstack projects);</div><div>* 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.</div><div>* And generally: ongoing commitment to being around in the right collaboration places to help folks out with Ansible + OpenStack questions if needed. </div><div>* Also: Tell the world the sig exists in various channels and ways, and to come join in the fun. :D</div><div><br></div><div>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. :)</div><div><br></div><div>***</div><div><br></div><div>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:</div><div><br></div><div>* 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.)</div><div>* 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.)</div><div><br></div><div>(Example: <a href="https://github.com/ansible/community/tree/master/group-windows">https://github.com/ansible/community/tree/master/group-windows</a> is the Windows Working Group, and has basic collaboration info, points to wiki space for collaboration, etc.)</div><div><br></div><div>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. </div><div><br></div><div>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)<br></div><div><br></div><div>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)</div><div><br></div><div>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. :)</div><div><br></div><div>Cheers,</div><div><br></div><div>-r</div></div>