Open Stack

Adam Spiers <aspiers at suse.com> writes:

> Doug Hellmann <doug at doughellmann.com> wrote: 
>>Adam Spiers <aspiers at suse.com> writes: 
>>>Thierry Carrez <thierry at 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