Open Stack

Ildiko Vancsa <ildiko.vancsa at gmail.com> wrote: 
>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: 
>>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.

Makes perfect sense to me - thanks for sharing!

>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?

I'm not sure if it would help.  But I agree that visibility is
important, and by extension also discoverability.  To that end I think
it would be worth hosting a central list of popup initiatives
somewhere which links to the available materials for each initiative.
Maybe it doesn't matter too much whether that central list is simply a
wiki page or a static web page managed by Gerrit under a governance
repo or similar.