settingsLogin | Registersettings

[openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

0 votes

Hi everyone,

One of the areas identified as a priority by the Board + TC + UC
workshop in March was the need to better close the feedback loop and
make unanswered requirements emerge. Part of the solution is to ensure
that groups that look at specific use cases, or specific problem spaces
within OpenStack get participation from a wide spectrum of roles, from
pure operators of OpenStack clouds, to upstream developers, product
managers, researchers, and every combination thereof. In the past year
we reorganized the Design Summit event, so that the design / planning /
feedback gathering part of it would be less dev- or ops-branded, to
encourage participation of everyone in a neutral ground, based on the
topic being discussed. That was just a first step.

In OpenStack we have a number of "working groups", groups of people
interested in discussing a given use case, or addressing a given problem
space across all of OpenStack. Examples include the API working group,
the Deployment working group, the Public clouds working group, the
Telco/NFV working group, or the Scientific working group. However, for
governance reasons, those are currently set up either as a User
Committee working group[1], or a working group depending on the
Technical Committee[2]. This branding of working groups artificially
discourages participation from one side to the others group, for no
specific reason. This needs to be fixed.

We propose to take a page out of Kubernetes playbook and set up "SIGs"
(special interest groups), that would be primarily defined by their
mission (i.e. the use case / problem space the group wants to
collectively address). Those SIGs would not be Ops SIGs or Dev SIGs,
they would just be OpenStack SIGs. While possible some groups will lean
more towards an operator or dev focus (based on their mission), it is
important to encourage everyone to join in early and often. SIGs could
be very easily set up, just by adding your group to a wiki page,
defining the mission of the group, a contact point and details on
meetings (if the group has any). No need for prior vetting by any
governance body. The TC and UC would likely still clean up dead SIGs
from the list, to keep it relevant and tidy. Since they are neither dev
or ops, SIGs would not use the -dev or the -operators lists: they would
use a specific ML (openstack-sigs ?) to hold their discussions without
cross-posting, with appropriate subject tagging.

Not everything would become a SIG. Upstream project teams would remain
the same (although some of them, like Security, might turn into a SIG).
Teams under the UC that are purely operator-facing (like the Ops Tags
Team or the AUC recognition team) would likewise stay as UC subteams.

Comments, thoughts ?

[1]
https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#Working_Groups_and_Teams
[2] https://wiki.openstack.org/wiki/Upstream_Working_Groups

--
Melvin Hillsman & Thierry Carrez


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 5, 2017 in openstack-dev by Thierry_Carrez (57,480 points)   3 8 12

20 Responses

0 votes

On 6/21/2017 9:59 AM, Thierry Carrez wrote:
Hi everyone,

One of the areas identified as a priority by the Board + TC + UC
workshop in March was the need to better close the feedback loop and
make unanswered requirements emerge. Part of the solution is to ensure
that groups that look at specific use cases, or specific problem spaces
within OpenStack get participation from a wide spectrum of roles, from
pure operators of OpenStack clouds, to upstream developers, product
managers, researchers, and every combination thereof. In the past year
we reorganized the Design Summit event, so that the design / planning /
feedback gathering part of it would be less dev- or ops-branded, to
encourage participation of everyone in a neutral ground, based on the
topic being discussed. That was just a first step.

In OpenStack we have a number of "working groups", groups of people
interested in discussing a given use case, or addressing a given problem
space across all of OpenStack. Examples include the API working group,
the Deployment working group, the Public clouds working group, the
Telco/NFV working group, or the Scientific working group. However, for
governance reasons, those are currently set up either as a User
Committee working group[1], or a working group depending on the
Technical Committee[2]. This branding of working groups artificially
discourages participation from one side to the others group, for no
specific reason. This needs to be fixed.

We propose to take a page out of Kubernetes playbook and set up "SIGs"
(special interest groups), that would be primarily defined by their
mission (i.e. the use case / problem space the group wants to
collectively address). Those SIGs would not be Ops SIGs or Dev SIGs,
they would just be OpenStack SIGs. While possible some groups will lean
more towards an operator or dev focus (based on their mission), it is
important to encourage everyone to join in early and often. SIGs could
be very easily set up, just by adding your group to a wiki page,
defining the mission of the group, a contact point and details on
meetings (if the group has any). No need for prior vetting by any
governance body. The TC and UC would likely still clean up dead SIGs
from the list, to keep it relevant and tidy. Since they are neither dev
or ops, SIGs would not use the -dev or the -operators lists: they would
use a specific ML (openstack-sigs ?) to hold their discussions without
cross-posting, with appropriate subject tagging.

Not everything would become a SIG. Upstream project teams would remain
the same (although some of them, like Security, might turn into a SIG).
Teams under the UC that are purely operator-facing (like the Ops Tags
Team or the AUC recognition team) would likewise stay as UC subteams.

Comments, thoughts ?

[1]
https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#Working_Groups_and_Teams
[2] https://wiki.openstack.org/wiki/Upstream_Working_Groups

How does the re-branding or re-categorization of these groups solve the
actual feedback problem? If the problem is getting different people from
different groups together, how does this solve that? For example, how do
we get upstream developers aware of operator issues or product managers
communicating their needs and feature priorities to the upstream
developers? No one can join all work groups or SIGs and be aware of all
things at the same time, and actually have time to do anything else.

Is the number of various work groups/SIGs a problem?

Maybe what I'd need is an example of an existing problem case and how
the new SIG model would fix that - concrete examples would be really
appreciated when communicating suggested governance changes.

For example, is there some feature/requirement/issue that one group has
wanted implemented/fixed for a long time but another group isn't aware
of it? How would SIGs fix that in a way that work groups haven't?

--

Thanks,

Matt


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2017 by mriedemos_at_gmail.c (15,720 points)   2 4 5
0 votes

Matt Riedemann wrote:
How does the re-branding or re-categorization of these groups solve the
actual feedback problem? If the problem is getting different people from
different groups together, how does this solve that? For example, how do
we get upstream developers aware of operator issues or product managers
communicating their needs and feature priorities to the upstream
developers?

My hope is that specific developers interested in a given use case or a
given problem space would join the corresponding SIG and discuss with
operators in the same SIG. As an example, imagine an upstream developer
from CERN, able to join the Scientific SIG to discuss with operators and
users with Scientific/Academic needs of the feature gap, and group with
other like-minded developers to get that feature gap collectively addressed.

No one can join all work groups or SIGs and be aware of all
things at the same time, and actually have time to do anything else.
Is the number of various work groups/SIGs a problem?

I would not expect everyone to join every SIG. I would actually expect
most people to join 0 or 1 SIG.

Maybe what I'd need is an example of an existing problem case and how
the new SIG model would fix that - concrete examples would be really
appreciated when communicating suggested governance changes.

For example, is there some feature/requirement/issue that one group has
wanted implemented/fixed for a long time but another group isn't aware
of it? How would SIGs fix that in a way that work groups haven't?

Two examples:

  • the "API WG" was started by people on the UC side, listed as a UC
    workgroup, and wasn't making much progress as it was missing devs. Now
    it's been reborn as a TC workgroup, led by a couple of devs, and is
    lacking app user input. Artificial barriers discourage people to join.
    Let's just call all of them SIGs.

  • the "Public Cloud WG" tries to cover an extremely important use case
    for all of OpenStack (we all need successful OpenStack public clouds).
    However, so far I've hardly seen a developer joining, because it's seen
    as an Ops group just trying to make requirements emerge. I want the few
    developers that OVH or CityCloud or other public clouds are ready to
    throw upstream to use the rebranded "Public Cloud SIG" as a rally point,
    to coordinate their actions. Because if they try to affect upstream
    separately, they won't go far, and we badly need them involved.

Yes, it's mostly a rebranding exercise, but perception matters.
Hope this clarifies,

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2017 by Thierry_Carrez (57,480 points)   3 8 12
0 votes

Hi,

In the past, governance has helped (on the UC WG side) to reduce
overlaps/duplication in WGs chartered for similar objectives. I would like
to understand how we will handle this (if at all) with the new SIG proposa?
Also, do we have to replace WGs as a concept or could SIG augment them? One
suggestion I have would be to keep projects on the TC side and WGs on the
UC side and then allow for spin-up/spin-down of SIGs as needed for
accomplishing specific goals/tasks (picture of a diagram I created at the
Forum[1]).

The WGs could focus on defining key objectives for users of a shared group
(market vertical like Enterprise or Scientific WG, horizontal function like
PWG) and then SIGs could be created based on this list to accomplish the
objective and spin-down. Similarly a project team could determine a need to
gather additional data/requirements or need help with a certain task could
also spin-up a SIG to accomplish it (e.g. updating an outdated docs set,
discussion on a specific spec that needs to be more thoroughly crafted,
etc.)

Finally, how will this change impact the ATC/AUC status of the SIG members
for voting rights in the TC/UC elections?

[1] https://drive.google.com/file/d/0B_yCSDGnhIbzS3V1b1lpZGpIaHBmc29S
aUdiYzJtX21BWkl3/

Thanks,
Shamail

On Wed, Jun 21, 2017 at 11:26 AM, Thierry Carrez thierry@openstack.org
wrote:

Matt Riedemann wrote:

How does the re-branding or re-categorization of these groups solve the
actual feedback problem? If the problem is getting different people from
different groups together, how does this solve that? For example, how do
we get upstream developers aware of operator issues or product managers
communicating their needs and feature priorities to the upstream
developers?

My hope is that specific developers interested in a given use case or a
given problem space would join the corresponding SIG and discuss with
operators in the same SIG. As an example, imagine an upstream developer
from CERN, able to join the Scientific SIG to discuss with operators and
users with Scientific/Academic needs of the feature gap, and group with
other like-minded developers to get that feature gap collectively
addressed.

No one can join all work groups or SIGs and be aware of all
things at the same time, and actually have time to do anything else.
Is the number of various work groups/SIGs a problem?

I would not expect everyone to join every SIG. I would actually expect
most people to join 0 or 1 SIG.

Maybe what I'd need is an example of an existing problem case and how
the new SIG model would fix that - concrete examples would be really
appreciated when communicating suggested governance changes.

For example, is there some feature/requirement/issue that one group has
wanted implemented/fixed for a long time but another group isn't aware
of it? How would SIGs fix that in a way that work groups haven't?

Two examples:

  • the "API WG" was started by people on the UC side, listed as a UC
    workgroup, and wasn't making much progress as it was missing devs. Now
    it's been reborn as a TC workgroup, led by a couple of devs, and is
    lacking app user input. Artificial barriers discourage people to join.
    Let's just call all of them SIGs.

  • the "Public Cloud WG" tries to cover an extremely important use case
    for all of OpenStack (we all need successful OpenStack public clouds).
    However, so far I've hardly seen a developer joining, because it's seen
    as an Ops group just trying to make requirements emerge. I want the few
    developers that OVH or CityCloud or other public clouds are ready to
    throw upstream to use the rebranded "Public Cloud SIG" as a rally point,
    to coordinate their actions. Because if they try to affect upstream
    separately, they won't go far, and we badly need them involved.

Yes, it's mostly a rebranding exercise, but perception matters.
Hope this clarifies,

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2017 by Shamail (5,040 points)   1 2 3
0 votes

Shamail Tahir wrote:
In the past, governance has helped (on the UC WG side) to reduce
overlaps/duplication in WGs chartered for similar objectives. I would
like to understand how we will handle this (if at all) with the new SIG
proposa?

I tend to think that any overlap/duplication would get solved naturally,
without having to force everyone through an application process that may
discourage natural emergence of such groups. I feel like an application
process would be premature optimization. We can always encourage groups
to merge (or clean them up) after the fact. How much
overlaps/duplicative groups did you end up having ?

Also, do we have to replace WGs as a concept or could SIG
augment them? One suggestion I have would be to keep projects on the TC
side and WGs on the UC side and then allow for spin-up/spin-down of SIGs
as needed for accomplishing specific goals/tasks (picture of a diagram
I created at the Forum[1]).

I feel like most groups should be inclusive of all community, so I'd
rather see the SIGs being the default, and ops-specific or dev-specific
groups the exception. To come back to my Public Cloud WG example, you
need to have devs and ops in the same group in the first place before
you would spin-up a "address scalability" SIG. Why not just have a
Public Cloud SIG in the first place?

[...]
Finally, how will this change impact the ATC/AUC status of the SIG
members for voting rights in the TC/UC elections?

There are various options. Currently you give UC WG leads the AUC
status. We could give any SIG lead both statuses. Or only give the AUC
status to a subset of SIGs that the UC deems appropriate. It's really an
implementation detail imho. (Also I would expect any SIG lead to already
be both AUC and ATC somehow anyway, so that may be a non-issue).

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2017 by Thierry_Carrez (57,480 points)   3 8 12
0 votes

On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez thierry@openstack.org
wrote:

Shamail Tahir wrote:

In the past, governance has helped (on the UC WG side) to reduce
overlaps/duplication in WGs chartered for similar objectives. I would
like to understand how we will handle this (if at all) with the new SIG
proposa?

I tend to think that any overlap/duplication would get solved naturally,
without having to force everyone through an application process that may
discourage natural emergence of such groups. I feel like an application
process would be premature optimization. We can always encourage groups
to merge (or clean them up) after the fact. How much
overlaps/duplicative groups did you end up having ?

Fair point, it wasn't many. The reason I recalled this effort was because
we had to go through the exercise after the fact and that made the volume
of WGs to review much larger than had we asked the purpose whenever they
were created. As long as we check back periodically and not let the work
for validation/clean up pile up then this is probably a non-issue.

Also, do we have to replace WGs as a concept or could SIG
augment them? One suggestion I have would be to keep projects on the TC
side and WGs on the UC side and then allow for spin-up/spin-down of SIGs
as needed for accomplishing specific goals/tasks (picture of a diagram
I created at the Forum[1]).

I feel like most groups should be inclusive of all community, so I'd
rather see the SIGs being the default, and ops-specific or dev-specific
groups the exception. To come back to my Public Cloud WG example, you
need to have devs and ops in the same group in the first place before
you would spin-up a "address scalability" SIG. Why not just have a
Public Cloud SIG in the first place?

+1, I interpreted originally that each use-case would be a SIG versus the
SIG being able to be segment oriented (in which multiple use-cases could be
pursued)

[...]
Finally, how will this change impact the ATC/AUC status of the SIG
members for voting rights in the TC/UC elections?

There are various options. Currently you give UC WG leads the AUC
status. We could give any SIG lead both statuses. Or only give the AUC
status to a subset of SIGs that the UC deems appropriate. It's really an
implementation detail imho. (Also I would expect any SIG lead to already
be both AUC and ATC somehow anyway, so that may be a non-issue).

We can discuss this later because it really is an implementation detail.
Thanks for the answers.

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2017 by Shamail (5,040 points)   1 2 3
0 votes

On 6/21/2017 11:17 AM, Shamail Tahir wrote:

On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez <thierry@openstack.org
thierry@openstack.org> wrote:

Shamail Tahir wrote:
> In the past, governance has helped (on the UC WG side) to reduce
> overlaps/duplication in WGs chartered for similar objectives. I would
> like to understand how we will handle this (if at all) with the new SIG
> proposa?

I tend to think that any overlap/duplication would get solved naturally,
without having to force everyone through an application process that may
discourage natural emergence of such groups. I feel like an application
process would be premature optimization. We can always encourage groups
to merge (or clean them up) after the fact. How much
overlaps/duplicative groups did you end up having ?

Fair point, it wasn't many. The reason I recalled this effort was
because we had to go through the exercise after the fact and that made
the volume of WGs to review much larger than had we asked the purpose
whenever they were created. As long as we check back periodically and
not let the work for validation/clean up pile up then this is probably a
non-issue.

> Also, do we have to replace WGs as a concept or could SIG
> augment them? One suggestion I have would be to keep projects on the TC
> side and WGs on the UC side and then allow for spin-up/spin-down of SIGs
> as needed for accomplishing specific goals/tasks (picture of a  diagram
> I created at the Forum[1]).

I feel like most groups should be inclusive of all community, so I'd
rather see the SIGs being the default, and ops-specific or dev-specific
groups the exception. To come back to my Public Cloud WG example, you
need to have devs and ops in the same group in the first place before
you would spin-up a "address scalability" SIG. Why not just have a
Public Cloud SIG in the first place?

+1, I interpreted originally that each use-case would be a SIG versus
the SIG being able to be segment oriented (in which multiple use-cases
could be pursued)

 > [...]
> Finally, how will this change impact the ATC/AUC status of the SIG
> members for voting rights in the TC/UC elections?

There are various options. Currently you give UC WG leads the AUC
status. We could give any SIG lead both statuses. Or only give the AUC
status to a subset of SIGs that the UC deems appropriate. It's really an
implementation detail imho. (Also I would expect any SIG lead to already
be both AUC and ATC somehow anyway, so that may be a non-issue).

We can discuss this later because it really is an implementation detail.
Thanks for the answers.

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think a key point you're going to want to convey and repeat ad nauseum
with this SIG idea is that each SIG is focused on a specific use case
and they can be spun up and spun down. Assuming that's what you want
them to be.

One problem I've seen with the various work groups is they overlap in a
lot of ways but are probably driven as silos. For example, how many
different work groups are there that care about scaling? So rather than
have 5 work groups that all overlap on some level for a specific issue,
create a SIG for that specific issue so the people involved can work on
defining the specific problem and work to come up with a solution that
can then be implemented by the upstream development teams, either within
a single project or across projects depending on the issue. And once the
specific issue is resolved, close down the SIG.

Examples here would be things that fall under proposed community wide
goals for a release, like running API services under wsgi, py3 support,
moving policy rules into code, hierarchical quotas, RBAC "admin of
admins" policy changes, etc. Have a SIG that is comprised of people with
different roles (project managers, product managers, operators,
developers, docs, QA) that are focused on solving that one specific
issue and drive it, and then close it down once some completion criteria
is met.

That still doesn't mean you're going to get the attendance you need from
all parties. I don't know how you solve that one. People are going to
work on what they are paid to work on.

--

Thanks,

Matt


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2017 by mriedemos_at_gmail.c (15,720 points)   2 4 5
0 votes

One of key components which, imho, made SIGs successful in k8s is
infrastructure behind it.

When someone proposes an issue, they can tag SIG to it. Everyone in
this SIG will be notified that there is an issue they might be
interested it, they check it out and provide feedback. That also
creates additional familiarity with dev toolset for non-dev sig
members. I think what would be important for OpenStack SIGs to be
successful is connecting SIGs to both Launchpad and Gerrit.

For example:
New blueprint is introduced to Kolla-ansible that allows easy PCI
passthrough, we tag HPC and Scientific SIGs and everyone is notified
(via mail) that there is this thing in project Kolla they might want
to check out.
New change is proposed that addresses important issue - also tag SIGs
to encourage their reviews on actual implementation.

I think github gives good all-in-one toolset for SIG mgmt, issue mgmt,
code reviews and all. With our diverse tools this will be more
challenging, but important. And yes, we need SIG people to have
visibility into gerrit. If you ask me what's biggest problem in
OpenStack I'd say that operator community don't review implementation
details enough. Having notifs pushed into them would hopefully change
this a little bit.

On 21 June 2017 at 09:55, Matt Riedemann mriedemos@gmail.com wrote:
On 6/21/2017 11:17 AM, Shamail Tahir wrote:

On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez <thierry@openstack.org
thierry@openstack.org> wrote:

Shamail Tahir wrote:
> In the past, governance has helped (on the UC WG side) to reduce
> overlaps/duplication in WGs chartered for similar objectives. I

would

like to understand how we will handle this (if at all) with the new
SIG
proposa?

I tend to think that any overlap/duplication would get solved

naturally,
without having to force everyone through an application process that
may
discourage natural emergence of such groups. I feel like an
application
process would be premature optimization. We can always encourage
groups
to merge (or clean them up) after the fact. How much
overlaps/duplicative groups did you end up having ?

Fair point, it wasn't many. The reason I recalled this effort was because
we had to go through the exercise after the fact and that made the volume of
WGs to review much larger than had we asked the purpose whenever they were
created. As long as we check back periodically and not let the work for
validation/clean up pile up then this is probably a non-issue.

> Also, do we have to replace WGs as a concept or could SIG
> augment them? One suggestion I have would be to keep projects on the

TC

side and WGs on the UC side and then allow for spin-up/spin-down of
SIGs
as needed for accomplishing specific goals/tasks (picture of a
diagram
I created at the Forum[1]).

I feel like most groups should be inclusive of all community, so I'd
rather see the SIGs being the default, and ops-specific or

dev-specific
groups the exception. To come back to my Public Cloud WG example, you
need to have devs and ops in the same group in the first place before
you would spin-up a "address scalability" SIG. Why not just have a
Public Cloud SIG in the first place?

+1, I interpreted originally that each use-case would be a SIG versus the
SIG being able to be segment oriented (in which multiple use-cases could be
pursued)

 > [...]
> Finally, how will this change impact the ATC/AUC status of the SIG
> members for voting rights in the TC/UC elections?

There are various options. Currently you give UC WG leads the AUC
status. We could give any SIG lead both statuses. Or only give the AUC
status to a subset of SIGs that the UC deems appropriate. It's really

an
implementation detail imho. (Also I would expect any SIG lead to
already
be both AUC and ATC somehow anyway, so that may be a non-issue).

We can discuss this later because it really is an implementation detail.
Thanks for the answers.

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think a key point you're going to want to convey and repeat ad nauseum
with this SIG idea is that each SIG is focused on a specific use case and
they can be spun up and spun down. Assuming that's what you want them to be.

One problem I've seen with the various work groups is they overlap in a lot
of ways but are probably driven as silos. For example, how many different
work groups are there that care about scaling? So rather than have 5 work
groups that all overlap on some level for a specific issue, create a SIG for
that specific issue so the people involved can work on defining the specific
problem and work to come up with a solution that can then be implemented by
the upstream development teams, either within a single project or across
projects depending on the issue. And once the specific issue is resolved,
close down the SIG.

Examples here would be things that fall under proposed community wide goals
for a release, like running API services under wsgi, py3 support, moving
policy rules into code, hierarchical quotas, RBAC "admin of admins" policy
changes, etc. Have a SIG that is comprised of people with different roles
(project managers, product managers, operators, developers, docs, QA) that
are focused on solving that one specific issue and drive it, and then close
it down once some completion criteria is met.

That still doesn't mean you're going to get the attendance you need from all
parties. I don't know how you solve that one. People are going to work on
what they are paid to work on.

--

Thanks,

Matt


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2017 by Michał_Jastrzębski (9,220 points)   1 4 5
0 votes

On 06/21/2017 11:55 AM, Matt Riedemann wrote:
On 6/21/2017 11:17 AM, Shamail Tahir wrote:

On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez
<thierry@openstack.org thierry@openstack.org> wrote:

Shamail Tahir wrote:
> In the past, governance has helped (on the UC WG side) to reduce
> overlaps/duplication in WGs chartered for similar objectives. I

would

like to understand how we will handle this (if at all) with the
new SIG
proposa?

I tend to think that any overlap/duplication would get solved

naturally,
without having to force everyone through an application process
that may
discourage natural emergence of such groups. I feel like an
application
process would be premature optimization. We can always encourage
groups
to merge (or clean them up) after the fact. How much
overlaps/duplicative groups did you end up having ?

Fair point, it wasn't many. The reason I recalled this effort was
because we had to go through the exercise after the fact and that
made the volume of WGs to review much larger than had we asked the
purpose whenever they were created. As long as we check back
periodically and not let the work for validation/clean up pile up
then this is probably a non-issue.

> Also, do we have to replace WGs as a concept or could SIG
> augment them? One suggestion I have would be to keep projects

on the TC

side and WGs on the UC side and then allow for
spin-up/spin-down of SIGs
as needed for accomplishing specific goals/tasks (picture of a
diagram
I created at the Forum[1]).

I feel like most groups should be inclusive of all community, so I'd
rather see the SIGs being the default, and ops-specific or

dev-specific
groups the exception. To come back to my Public Cloud WG example,
you
need to have devs and ops in the same group in the first place
before
you would spin-up a "address scalability" SIG. Why not just have a
Public Cloud SIG in the first place?

+1, I interpreted originally that each use-case would be a SIG versus
the SIG being able to be segment oriented (in which multiple
use-cases could be pursued)

 > [...]
> Finally, how will this change impact the ATC/AUC status of the SIG
> members for voting rights in the TC/UC elections?

There are various options. Currently you give UC WG leads the AUC
status. We could give any SIG lead both statuses. Or only give

the AUC
status to a subset of SIGs that the UC deems appropriate. It's
really an
implementation detail imho. (Also I would expect any SIG lead to
already
be both AUC and ATC somehow anyway, so that may be a non-issue).

We can discuss this later because it really is an implementation
detail. Thanks for the answers.

--

Thierry Carrez (ttx)



OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think a key point you're going to want to convey and repeat ad
nauseum with this SIG idea is that each SIG is focused on a specific
use case and they can be spun up and spun down. Assuming that's what
you want them to be.

One problem I've seen with the various work groups is they overlap in
a lot of ways but are probably driven as silos. For example, how many
different work groups are there that care about scaling? So rather
than have 5 work groups that all overlap on some level for a specific
issue, create a SIG for that specific issue so the people involved can
work on defining the specific problem and work to come up with a
solution that can then be implemented by the upstream development
teams, either within a single project or across projects depending on
the issue. And once the specific issue is resolved, close down the SIG.

Examples here would be things that fall under proposed community wide
goals for a release, like running API services under wsgi, py3
support, moving policy rules into code, hierarchical quotas, RBAC
"admin of admins" policy changes, etc. Have a SIG that is comprised of
people with different roles (project managers, product managers,
operators, developers, docs, QA) that are focused on solving that one
specific issue and drive it, and then close it down once some
completion criteria is met.

I was just going to say the policy efforts sound like a great candidate
for a SIG. We held off on making it a working group until there was a
need for it. We hold a weekly meeting but it'd be nice to get more
involvement from project managers, operators, products, etc. But, like
Matt said, I'm not sure how to encourage that involvement outside of
methods we've already tried.

That still doesn't mean you're going to get the attendance you need
from all parties. I don't know how you solve that one. People are
going to work on what they are paid to work on.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Jun 21, 2017 by Lance_Bragstad (11,080 points)   2 3 4
0 votes

to put my public cloud wg hat on, I think the lack of coordination is a
common problems among OpenStack WGs but I think transitioning WGs to SIGs
will help solving the issue alone.

I think from my observations from existing WGs, the mechanism that are now
in place works great, we have many productive output coming out of WGs.

The core problem here is how WG chairs establish a working method with PTLs
of related project each cycle, so that both side understand each other and
important matters getting solved in the near cycles. The dev circles and
non-dev circles are fairly isolated at the moment.

Merely rebranding WGs won't solve this core problem, I would recommend the
following actions:

  1. In addition to the current TC/UC/Projects/WG mechanism, allow people to
    establish adhoc SIGs without any procedure overhead (getting approved by
    any entity). Folks in the spontaneously established SIGs could find their
    best way to get their requirement done. We could have an overall wiki page
    for collection/registration of all the SIGs created.

  2. Enhance dev/non-dev comms. I doubt more meetings will be the solution.

a. I would suggest projects when doing their planning at Forum or PTG,
always leave a spot for requirement from WGs. And WG chairs should
participate this dev meetings if their WG has done related work.
b. Moreover the foundation could start promotion of project/WG
collaboration best practices, or even specify in the release document that
certain feature are based upon feedback from a certain WGs.

c. WG should have cycle-based releases of works so that they got a sense of
timing, no lost in a permanent discussion mode for issues.

My 2 cents

On Thu, Jun 22, 2017 at 1:33 AM, Lance Bragstad lbragstad@gmail.com wrote:

On 06/21/2017 11:55 AM, Matt Riedemann wrote:

On 6/21/2017 11:17 AM, Shamail Tahir wrote:

On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez
<thierry@openstack.org thierry@openstack.org> wrote:

Shamail Tahir wrote:
> In the past, governance has helped (on the UC WG side) to reduce
> overlaps/duplication in WGs chartered for similar objectives. I

would

like to understand how we will handle this (if at all) with the
new SIG
proposa?

I tend to think that any overlap/duplication would get solved

naturally,
without having to force everyone through an application process
that may
discourage natural emergence of such groups. I feel like an
application
process would be premature optimization. We can always encourage
groups
to merge (or clean them up) after the fact. How much
overlaps/duplicative groups did you end up having ?

Fair point, it wasn't many. The reason I recalled this effort was
because we had to go through the exercise after the fact and that
made the volume of WGs to review much larger than had we asked the
purpose whenever they were created. As long as we check back
periodically and not let the work for validation/clean up pile up
then this is probably a non-issue.

> Also, do we have to replace WGs as a concept or could SIG
> augment them? One suggestion I have would be to keep projects

on the TC

side and WGs on the UC side and then allow for
spin-up/spin-down of SIGs
as needed for accomplishing specific goals/tasks (picture of a
diagram
I created at the Forum[1]).

I feel like most groups should be inclusive of all community, so I'd
rather see the SIGs being the default, and ops-specific or

dev-specific
groups the exception. To come back to my Public Cloud WG example,
you
need to have devs and ops in the same group in the first place
before
you would spin-up a "address scalability" SIG. Why not just have a
Public Cloud SIG in the first place?

+1, I interpreted originally that each use-case would be a SIG versus
the SIG being able to be segment oriented (in which multiple
use-cases could be pursued)

 > [...]
> Finally, how will this change impact the ATC/AUC status of the SIG
> members for voting rights in the TC/UC elections?

There are various options. Currently you give UC WG leads the AUC
status. We could give any SIG lead both statuses. Or only give

the AUC
status to a subset of SIGs that the UC deems appropriate. It's
really an
implementation detail imho. (Also I would expect any SIG lead to
already
be both AUC and ATC somehow anyway, so that may be a non-issue).

We can discuss this later because it really is an implementation
detail. Thanks for the answers.

--
Thierry Carrez (ttx)



OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time



OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think a key point you're going to want to convey and repeat ad
nauseum with this SIG idea is that each SIG is focused on a specific
use case and they can be spun up and spun down. Assuming that's what
you want them to be.

One problem I've seen with the various work groups is they overlap in
a lot of ways but are probably driven as silos. For example, how many
different work groups are there that care about scaling? So rather
than have 5 work groups that all overlap on some level for a specific
issue, create a SIG for that specific issue so the people involved can
work on defining the specific problem and work to come up with a
solution that can then be implemented by the upstream development
teams, either within a single project or across projects depending on
the issue. And once the specific issue is resolved, close down the SIG.

Examples here would be things that fall under proposed community wide
goals for a release, like running API services under wsgi, py3
support, moving policy rules into code, hierarchical quotas, RBAC
"admin of admins" policy changes, etc. Have a SIG that is comprised of
people with different roles (project managers, product managers,
operators, developers, docs, QA) that are focused on solving that one
specific issue and drive it, and then close it down once some
completion criteria is met.

I was just going to say the policy efforts sound like a great candidate
for a SIG. We held off on making it a working group until there was a
need for it. We hold a weekly meeting but it'd be nice to get more
involvement from project managers, operators, products, etc. But, like
Matt said, I'm not sure how to encourage that involvement outside of
methods we've already tried.

That still doesn't mean you're going to get the attendance you need
from all parties. I don't know how you solve that one. People are
going to work on what they are paid to work on.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 22, 2017 by Zhipeng_Huang (6,720 points)   2 3 3
0 votes

On 21/06/17 08:41 PM, Zhipeng Huang wrote:
2. Enhance dev/non-dev comms. I doubt more meetings will be the solution.

a. I would suggest projects when doing their planning at Forum or
PTG, always leave a spot for requirement from WGs. And WG chairs
should participate this dev meetings if their WG has done related work.
b. Moreover the foundation could start promotion of project/WG
collaboration best practices, or even specify in the release
document that certain feature are based upon feedback from a certain
WGs.

c. WG should have cycle-based releases of works so that they got a
sense of timing, no lost in a permanent discussion mode for issues.

agree that we need to stop being so silo'd. i would suggest even more
regular feedback rather than a once a cycle data dump at the forum.

i don't attend WG meetings/discussions but i'm curious, do the Working
Groups have resource to contact the desired PTLs bi-weekly/(some regular
interval) to give feedback and discuss requirements? given the lack of
resources in community dev teams, i would expect better results if WG
members could initiate communication... or go 51% at least :)

--
gord


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 22, 2017 by gordon_chung (19,300 points)   2 3 7
...