Open Stack

Currently cross project work is very hard due to contributors not having enough political capital (review capital) in each project to get attention/priority. By the TC putting its weight behind a popupgroup, the projects can know, that this is important, even though I haven't seen that contributor much before.

They may not need git repo's but new IRC channels do make sense I think. Sometimes you need to coordinate work between projects and trying to do that in one of the project channels might not facilitate that.

Thanks,
Kevin
________________________________________
From: Doug Hellmann [doug at doughellmann.com]
Sent: Thursday, February 07, 2019 7:58 AM
To: Adam Spiers; Thierry Carrez
Cc: Sean McGinnis; openstack-discuss at lists.openstack.org
Subject: Re: [all][tc] Formalizing cross-project pop-up teams

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?

>
> 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? So I wouldn't expect them to need git
repositories or new IRC channels. Meeting times, yes.

>
> I'm not sure what the best approach is - sorry ;-)
>

--
Doug