Adam Spiers <aspiers@suse.com> writes:
Doug Hellmann <doug@doughellmann.com> wrote:
Adam Spiers <aspiers@suse.com> writes:
Thierry Carrez <thierry@openstack.org> wrote:
Adam Spiers wrote:
[...] Sure. I particularly agree with your point about processes; I think the TC (or whoever else volunteers) could definitely help lower the barrier to starting up a pop-up team by creating a cookie-cutter kind of approach which would quickly set up any required infrastructure. For example it could be a simple form or CLI-based tool posing questions like the following, where the answers could facilitate the bootstrapping process: - What is the name of your pop-up team? - Please enter a brief description of the purpose of your pop-up team. - If you will use an IRC channel, please state it here. - Do you need regular IRC meetings? - Do you need a new git repository? [If so, ...] - Do you need a new StoryBoard project? [If so, ...] - Do you need a [badge] for use in Subject: headers on openstack-discuss? etc.
The outcome of the form could be anything from pointers to specific bits of documentation on how to set up the various bits of infrastructure, all the way through to automation of as much of the setup as is possible. The slicker the process, the more agile the community could become in this respect.
That's a great idea -- if the pop-up team concept takes on we could definitely automate stuff. In the mean time I feel like the next step is to document what we mean by pop-up team, list them, and give pointers to the type of resources you can have access to (and how to ask for them).
Agreed - a quickstart document would be a great first step.
In terms of "blessing" do you think pop-up teams should be ultimately approved by the TC ? On one hand that adds bureaucracy / steps to the process, but on the other having some kind of official recognition can help them...
So maybe some after-the-fact recognition would work ? Let pop-up teams freely form and be listed, then have the TC declaring some of them (if not all of them) to be of public interest ?
Yeah, good questions. The official recognition is definitely beneficial; OTOH I agree that requiring steps up-front might deter some teams from materialising. Automating these as much as possible would reduce the risk of that.
What benefit do you perceive to having official recognition?
Difficult to quantify a cultural impact ... Maybe it's not a big deal, but I'm pretty sure it makes a difference in that news of "official" things seems to propagate along the various grapevines better than skunkworks initiatives. One possibility is that the TC is the mother of all other grapevines ;-) So if the TC is aware of something then (perhaps naively) I expect that the ensuing discussion will accelerate spreading of awareness amongst rest of the community. And of course there are other official communication channels which could have a similar effect.
One challenge I see facing an after-the-fact approach is that any requests for infrastructure (IRC channel / meetings / git repo / Storyboard project etc.) would still need to be approved in advance, and presumably a coordinated approach to approval might be more effective than one where some of these requests could be approved and others denied.
Isn't the point of these teams that they would be coordinating work within other existing projects?
Yes.
So I wouldn't expect them to need git repositories or new IRC channels.
Never? Code and documentation doesn't always naturally belong in a single project, especially when it relates to cross-project work. Similarly, if (say) Monasca, Vitrage, and Heat all need an IRC channel in which to collaborate on a specific topic, it seems fairly clear that none of #openstack-{monasca,vitrage,heat} are optimal choices.
What's wrong with #openstack-dev?
The self-healing SIG has both a dedicated git repository (for docs, code, and in order to be able to use StoryBoard) and a dedicated IRC channel. We find both useful.
Of course SIGs are more heavy-weight and long-lived so I'm not suggesting that all or even necessarily the majority of popup teams would need git/IRC. But I imagine it's possible in some cases, at least.
Right, SIGs are not designed to disappear after a task is done in the way that popup teams are. If a popup team is going to create code, it needs to end up in a repository that is owned and maintained by someone over the long term. If that requires a new repo, and one of the existing teams isn't a natural home, then I think a new regular team is likely a better fit for the task than a popup team. -- Doug