Open Stack

yeah, I don't think k8s working groups have repos, just sigs. as working groups are short lived. Popup Groups should be similar to working groups I think.

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

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.

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.