Open Stack

First of all I like the idea of pop-up teams.

> On 2019. Feb 8., at 10:18, Adam Spiers <aspiers at suse.com> wrote:
> 
> Doug Hellmann <doug at doughellmann.com> wrote: 
>> Adam Spiers <aspiers at suse.com> writes: 
>>> Doug Hellmann <doug at doughellmann.com> wrote: 
>>>> 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? 
> 
> Maybe nothing, or maybe it's too noisy - I dunno ;-)  Maybe the latter could be solved by setting up #openstack-breakout{1..10} for impromptu meetings where meetbot and channel logging are provided. 

I think the project channels along with #opentack-dev should be enough to start with. As we are talking about activities concerning multiple projects many of the conversations will naturally land in one of the project channels depending on the stage of the design/development/testing work.

Using the multi-attach work as an example we used the Cinder and Nova channels for daily communication which worked out well as we had all the stakeholders around without asking them to join yet-another-IRC-channel. Discussing more general items can happen on the regular meetings and details can be moved to the project channels where the details often hint which project team is the most affected. I would expect the pop-up team having representatives from all teams as well as all pop-up team members hanging out in all relevant project team channels.

As a fall back for high level, all-project topics I believe #openstack-dev is a good choice expecting most of the people being in that channel already while also gaining further visibility to the topic there.

>>> 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. 
> 
> True.  And for temporary docs / notes / brainstorming there's the wiki and etherpad.  So yeah, in terms of infrastructure maybe IRC meetings in one of the communal meeting channels is the only thing needed. 
> We'd still need to take care of ensuring that popups are easily discoverable by anyone, however.  And this ties in with the "should we require official approval" debate - maybe a halfway house is the right balance between red tape and agility?  For example, set up a table on a page like 
>   https://wiki.openstack.org/wiki/Popup_teams
> 
> and warmly encourage newly forming teams to register themselves by adding a row to that table.  Suggested columns: 
>   - Team name
>   - One-line summary of team purpose
>   - Expected life span (optional)
>   - Link to team wiki page or etherpad
>   - Link to IRC meeting schedule (if any)
>   - Other comments
> 
> Or if that's too much of a free-for-all, it could be a slightly more formal process of submitting a review to add a row to a page: 
>   https://governance.openstack.org/popup-teams/
> 
> which would be similar in spirit to: 
>   https://governance.openstack.org/sigs/
> 
> Either this or a wiki page would ensure that anyone can easily discover what teams are currently in existence, or have been in the past (since historical information is often useful too). 
> Just thinking out aloud … 

In my experience there are two crucial steps to make a cross-project team work successful. The first is making sure that the proposed new feature/enhancement is accepted by all teams. The second is to have supporters from every affected project team preferably also resulting in involvement during both design and review time maybe also during feature development and testing phase.

When these two steps are done you can work on the design part and making sure you have the work items prioritized on each side in a way that you don’t end up with road blocks that would delay the work by multiple release cycles.

To help with all this I would start the experiment with wiki pages and etherpads as these are all materials you can point to without too much formality to follow so the goals, drivers, supporters and progress are visible to everyone who’s interested and to the TC to follow-up on.

Do we expect an approval process to help with or even drive either of the crucial steps I listed above?

Thanks,
Ildikó