[all][tc] Formalizing cross-project pop-up teams
Adam Spiers
aspiers at suse.com
Mon Feb 11 22:26:41 UTC 2019
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.
More information about the openstack-discuss
mailing list