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@doughellmann.com] Sent: Thursday, February 07, 2019 7:58 AM To: Adam Spiers; Thierry Carrez Cc: Sean McGinnis; openstack-discuss@lists.openstack.org Subject: Re: [all][tc] Formalizing cross-project pop-up teams
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?
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