On Thu, Jan 31, 2019, at 11:19 AM, Thierry Carrez wrote:

TL;DR: Maybe to help with cross-project work we should formalize temporary teams with clear objective and disband criteria, under the model of Kubernetes "working groups".

Long version:

Work in OpenStack is organized around project teams, who each own a set of git repositories. One well-known drawback of this organization is that it makes cross-project work harder, as someone has to coordinate activities that ultimately affects multiple project teams.

We tried various ways to facilitate cross-project work in the past. It started with a top-level repository of cross-project specs, a formal effort which failed due to a disconnect between the spec approvers (TC), the people signed up to push the work, and the teams that would need to approve the independent work items.

This was replaced by more informal "champions", doing project-management and other heavy lifting to get things done cross-project. This proved successful, but champions are often facing an up-hill battle and often suffer from lack of visibility / blessing / validation.

SIGs are another construct that helps holding discussions and coordinating work around OpenStack problem spaces, beyond specific project teams. Those are great as a permanent structure, but sometimes struggle to translate into specific development work, and are a bit heavy-weight just to coordinate a given set of work items.

Community goals fill the gap between champions and SIGs by blessing a given set of cross-community goals for a given release. However, given their nature (being blessed by the TC at every cycle), they are a better fit for small, cycle-long objectives that affect most of the OpenStack project teams, and great to push consistency across all projects.

It feels like we are missing a way to formally describe a short-term, cross-project objective that only affects a number of teams, is not tied to a specific cycle, and organize work around a temporary team specifically formed to reach that objective. A team that would get support from the various affected project teams, increasing chances of success.

Kubernetes encountered the same problem, with work organized around owners and permanent SIGs. They created the concept of a "working group"[1] with a clear limited objective, and a clear disband criteria. I feel like adopting something like it in OpenStack could help with work that affects multiple projects. We would not name it "working group" since that's already overloaded in OpenStack, but maybe "pop-up team" to stress the temporary nature of it. We've been sort-of informally using those in the past, but maybe formalizing and listing them could help getting extra visibility and prioritization.

Thoughts? Alternate solutions?

I like the idea. One question is, how would these groups be bootstrapped? At the moment, SIGs are formed by 1) people express an interest in a common idea 2) the SIG is proposed and approved by the TC and UC chairs 3) profit. With a more cross-project, deliverable-focused type of group, you would need to have buy-in from all project teams involved before bringing it up for approval by the TC - but getting that buy-in from many different groups can be difficult if you aren't already a blessed group. And if you didn't get buy-in first and the group became approved anyway, project teams may be resentful of having new objectives imposed on them when they may not even agree it's the right direction.

Colleen

[1] https://github.com/kubernetes/community/blob/master/committee-steering/gover...

-- Thierry Carrez (ttx)

On Thu, Jan 31, 2019 at 4:22 AM Thierry Carrez thierry@openstack.org wrote:

TL;DR: Maybe to help with cross-project work we should formalize temporary teams with clear objective and disband criteria, under the model of Kubernetes "working groups".

Long version:

Work in OpenStack is organized around project teams, who each own a set of git repositories. One well-known drawback of this organization is that it makes cross-project work harder, as someone has to coordinate activities that ultimately affects multiple project teams.

We tried various ways to facilitate cross-project work in the past. It started with a top-level repository of cross-project specs, a formal effort which failed due to a disconnect between the spec approvers (TC), the people signed up to push the work, and the teams that would need to approve the independent work items.

This was replaced by more informal "champions", doing project-management and other heavy lifting to get things done cross-project. This proved successful, but champions are often facing an up-hill battle and often suffer from lack of visibility / blessing / validation.

SIGs are another construct that helps holding discussions and coordinating work around OpenStack problem spaces, beyond specific project teams. Those are great as a permanent structure, but sometimes struggle to translate into specific development work, and are a bit heavy-weight just to coordinate a given set of work items.

Community goals fill the gap between champions and SIGs by blessing a given set of cross-community goals for a given release. However, given their nature (being blessed by the TC at every cycle), they are a better fit for small, cycle-long objectives that affect most of the OpenStack project teams, and great to push consistency across all projects.

It feels like we are missing a way to formally describe a short-term, cross-project objective that only affects a number of teams, is not tied to a specific cycle, and organize work around a temporary team specifically formed to reach that objective. A team that would get support from the various affected project teams, increasing chances of success.

FWIW - I've participated in groups that have attempted to self-organize like this in the past, but without a formal blessing.

We started by socializing the problem and the need for a solution [0]. We scheduled reoccurring meetings around it [1], attempted to document progress [2], and spin up specific efforts to help us design a solution that worked for our community [3][4]. After we felt comfortable with what we had, we attempted to use cross-project specs [5] (which we abandoned for the reasons you mentioned) and community goals to start moving the needle [6]. We also attempted to document the outcomes using project specifications [7][8] and other tools [9]. The difference between what we did and what you're proposing, in my opinion, is that we didn't define our disband criteria very well [10][11] and no one officially blessed us by any means. We were just a group that collected around an issue we cared about solving. I do think the effort was useful and helped us make progress on a challenging problem, which we're still trying to resolve.

Outside of having a formal name, do we expect the "pop-up" teams to include processes that make what we went through easier? Ultimately, we still had to self-organize and do a bunch of socializing to make progress.

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107137.html [1] https://review.openstack.org/#/c/398500/ [2] https://etherpad.openstack.org/p/keystone-policy-meeting [3] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123069.html [4] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123331.html [5] https://review.openstack.org/#/c/523973/ [6] https://governance.openstack.org/tc/goals/queens/policy-in-code.html [7] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/p... [8] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/p... [9] https://trello.com/b/bpWycnwa/policy-roadmap [10] https://review.openstack.org/#/c/581800/ [11] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-03-16...

Kubernetes encountered the same problem, with work organized around owners and permanent SIGs. They created the concept of a "working group"[1] with a clear limited objective, and a clear disband criteria. I feel like adopting something like it in OpenStack could help with work that affects multiple projects. We would not name it "working group" since that's already overloaded in OpenStack, but maybe "pop-up team" to stress the temporary nature of it. We've been sort-of informally using those in the past, but maybe formalizing and listing them could help getting extra visibility and prioritization.

Thoughts? Alternate solutions?

[1]

https://github.com/kubernetes/community/blob/master/committee-steering/gover...

-- Thierry Carrez (ttx)

On Fri, Feb 01, 2019 at 12:49:19PM +0100, Thierry Carrez wrote:

Lance Bragstad wrote:

...

[..] Outside of having a formal name, do we expect the "pop-up" teams to include processes that make what we went through easier? Ultimately, we still had to self-organize and do a bunch of socializing to make progress.

I think being listed as a pop-up team would definitely facilitate getting mentioned in TC reports, community newsletters or other high-vsibility community communications. It would help getting space to meet at PTGs, too.

I guess this is the main value I see from this proposal. If it helps with visibility and communications around the effort then it does add some value to give them an official name.

I don't think it changes much else. Those working in the group will still need to socialize the changes they would like to make, get buy-in from the project teams affected that the design approach is good, and find enough folks interested in the changes to drive it forward and propose the patches and do the other work needed to get things to happen.

We can try looking at processes to help support that. But ultimately, as with most open source projects, I think it comes down to having enough people interested enough to get the work done.

Sean

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).

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 ?

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 Hellmann doug@doughellmann.com wrote:

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?

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.

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@suse.com] Sent: Thursday, February 07, 2019 12:21 PM To: Doug Hellmann Cc: Thierry Carrez; Sean McGinnis; openstack-discuss@lists.openstack.org Subject: Re: [all][tc] Formalizing cross-project pop-up teams

Doug Hellmann doug@doughellmann.com wrote:

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?

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.

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

On 2019. Feb 8., at 10:18, Adam Spiers aspiers@suse.com wrote:

Doug Hellmann doug@doughellmann.com wrote:

...

Adam Spiers aspiers@suse.com writes:

...

Doug Hellmann doug@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ó

Ildiko Vancsa ildiko.vancsa@gmail.com wrote:

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

On 2019. Feb 8., at 10:18, Adam Spiers aspiers@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.

Ildiko Vancsa ildiko.vancsa@gmail.com wrote:

...

On 2019. Feb 11., at 23:26, Adam Spiers aspiers@suse.com wrote: [snip…]

...

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.

I would start with a wiki page as it stores history as well and it’s easier to edit. Later on if we feel the need to be more formal we can move to a static web page and use Gerrit.

Sounds good to me. Do we already have some popup teams? If so we could set this up straight away.

On 2/13/19 6:24 AM, Adam Spiers wrote:

Ildiko Vancsa ildiko.vancsa@gmail.com wrote:

...

...

On 2019. Feb 11., at 23:26, Adam Spiers aspiers@suse.com wrote: [snip…]

...

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.

I would start with a wiki page as it stores history as well and it’s easier to edit. Later on if we feel the need to be more formal we can move to a static web page and use Gerrit.

Sounds good to me.  Do we already have some popup teams?  If so we could set this up straight away.

The unified limits work is certainly cross-project, but it's slowed down recently. There were a few folks from nova, keystone, and oslo working on various parts of it.

I definitely like the idea of a pop-up team in the house.

I also tend to agree with the opinion about visibility for a pop-up team. We definitely need something with quick workflow. And allow people directly start communicate and working on the goal.

Here's what I think we should do in advance.

1. To clear ways that we have to trigger cross-project development. To clear the path and to document.

People have been trying a few formats to work on cross-project spec. After time, some prove useful and gaining momentum on the way. And some getting less. But we never try to stop at a point and declare what's the way we should do cross-project. And I'm pretty sure that's very confused for a lot of people who might not always as a part of this community. To give official recognition for ways that we think will cover the patch, and to officially announce the unofficial for methods (which we might already done with in ML/Meeting, but it's worth to bringing it to a more visible place.). And most importantly to have it documented in our develop guidelines, so message we send will be crystal clear for all of us all the time.

If we can keep broadcast around and tell people how they can set-up for their requirement, than we actually get better chance to have more people trying the right way of engage with us and give really useful feedback.

IMO, to use SIG as long-term (and repository demanded) path, and have a pop-up team for short term trace sounds like a fully covered for me.

2. Remove annoying channels. I like the idea if only use a single irc channel to communicate for multiple purpose

I feel the lack of time to work through multiple channels and in multiple communities. Which is really annoying. So if we can have a general irc channel like openstack-dev, and allow popup-teams move to specific irc channel if they see fit. To consider have better visibility, a single channel for multiple team cores and leads to be awarded of some pop-up works will definitely a benefit. I mean, how many people actually capable to trace that much channel dally and happen to have time to join development? Isn't that's why we comes up with `openstack-discussion` for most mail to be in place? The down side is that we didn't have tag filter for irc. but that's also a good thing to actually know about works for pop-up teams.

3. Gaining visibility and official blessing As agree on comments about gaining visibility, a session for all SIGs and pop-up teams to shout out and raise their own most wanted help out. We can do it in one single session and give 3-5 minutes for each team. Any one also feel this is a good idea too?

On Thu, Feb 14, 2019 at 9:15 PM Thierry Carrez thierry@openstack.org wrote:

Adam Spiers wrote:

...

Ildiko Vancsa ildiko.vancsa@gmail.com wrote:

...

...

On 2019. Feb 11., at 23:26, Adam Spiers aspiers@suse.com wrote: [snip…]

...

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.

I would start with a wiki page as it stores history as well and it’s easier to edit. Later on if we feel the need to be more formal we can move to a static web page and use Gerrit.

Sounds good to me. Do we already have some popup teams? If so we could set this up straight away.

To continue this discussion, I just set up a basic page with an example team at:

https://wiki.openstack.org/wiki/Popup_Teams

Feel free to improve the description and example entry.

-- Thierry Carrez (ttx)