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

2017-07-05 Thread Blair Bethwaite 
On 27 June 2017 at 23:47, Sean Dague  wrote:
> I still think I've missed, or not grasped, during this thread how a SIG
> functions differently than a WG, besides name. Both in theory and practice.

I think for the most part SIG is just a more fitting moniker for some
of these groups. E.g. I would say the scientific-wg is really a SIG,
typically with a few loose sub-WGs at any time, but the bulk of the
active membership is largely people doing similar jobs and
deploying/using OpenStack for similar things across science/academia -
so we basically have a lot of "shop" to talk about, and sometimes that
is only peripherally related to OpenStack.

-- 
Cheers,
~Blairo

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

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

2017-06-27 Thread John Griffith 
On Wed, Jun 21, 2017 at 8: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
>
> --
> Melvin Hillsman & Thierry Carrez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

​I don't think this is necessarily where you're heading on this, but one
thing that's been kinda nice IMO working in some other upstream communities
(like K8's) that use the SIG model.  There's one channel for something like
storage, and to your point it's for everybody and anybody interested in
that topic.  Whether they're a developer, deployer or end-user.  I actually
think this works really well because it ensures that the same people that
are developing code are also directly exposed to and interacting with
various consumers of their code.

It also means people that will be consuming the code also may actually get
to contribute directly to the development process.  This would be a huge
win in my opinion.  The example is that rather than having a cinder channel
just for dev related conversations and a general openstack channel for
support and questions, throw all Cinder related things into a single
channel.  This means devs are actually in touch with ops and users which is
something that I think would be extremely beneficial.

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

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

2017-06-27 Thread Jeremy Stanley 
On 2017-06-27 15:42:05 +0200 (+0200), Thierry Carrez wrote:
> Sean Dague wrote:
[...]
> > I wonder if we're going down this path, if some kind of tooling like
> > standard tags for issues/patches should be added to the mix to help gain
> > the effectiveness that the k8s team seems to have here.
> 
> For Launchpad/Storyboard we could totally reuse tags. Absence of tags in
> gerrit bites us here (and in other places too). I know that was a
> planned feature, does anyone have updated status on it ?
[...]

Gerrit's "hashtag" feature relies on their new NoteDb backend and
new PolyGerrit frontend. It looks like we'll need to be running 2.14
at a minimum to have the working WebUI so that people can
conveniently set hashtags on changes. Due to a number of factors,
we're not planning to upgrade to 2.14 just yet (it was only released
two months ago, requires newer Java which in turn requires a newer
operating system) and are instead underway with testing the
stable-2.13 branch tip for our upcoming upgrade.

This aside, you could probably get somewhere with a combination of
commit message footers and topics, or some reverse-mapping from
tagged bugs/stories using, e.g., reviewday.
-- 
Jeremy Stanley


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

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

2017-06-27 Thread Sean Dague 
On 06/27/2017 09:42 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> I also think it's fine to rebrand WG to SIG, but we should also be
>> honest that it's mostly a rebrand to consolidate on terminology that k8s
>> and cncf have used that people find easier to understand so it's a way
>> in which openstack is not different than those. Consolidating on terms
>> isn't a bad thing, but it's really a minor part of the workflow issue.
> 
> It's both a consolidation and the signal of a change. If we continued to
> call them "workgroups" I suspect we'd carry some of the traditions
> around them (or would end up calling them new-style WG vs. old-style WG).

I still think I've missed, or not grasped, during this thread how a SIG
functions differently than a WG, besides name. Both in theory and practice.

The API WG doesn't seem like a great example, because it was honestly a
couple of people that were interested in API consumption, but mostly had
a historical view of how the API worked in OpenStack. The transition in
from developers was largely because some reality checking needed to be
put in place, and then people changed roles / jobs, and those showing up
stayed on the dev side.

-Sean

-- 
Sean Dague
http://dague.net

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

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

2017-06-27 Thread Thierry Carrez 
Sean Dague wrote:
> On 06/21/2017 01:10 PM, Michał Jastrzębski wrote:
>> 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.
> 
> I think this is a key point. The simpler tools that github has, which
> require that you build a workflow based on tags outside of the tools,
> actually enables the effectiveness here.
> 
> Does k8s community currently have the same level of operators that
> aren't developers participating as OpenStack?
> 
> I wonder if we're going down this path, if some kind of tooling like
> standard tags for issues/patches should be added to the mix to help gain
> the effectiveness that the k8s team seems to have here.

For Launchpad/Storyboard we could totally reuse tags. Absence of tags in
gerrit bites us here (and in other places too). I know that was a
planned feature, does anyone have updated status on it ?

> I also think it's fine to rebrand WG to SIG, but we should also be
> honest that it's mostly a rebrand to consolidate on terminology that k8s
> and cncf have used that people find easier to understand so it's a way
> in which openstack is not different than those. Consolidating on terms
> isn't a bad thing, but it's really a minor part of the workflow issue.

It's both a consolidation and the signal of a change. If we continued to
call them "workgroups" I suspect we'd carry some of the traditions
around them (or would end up calling them new-style WG vs. old-style WG).

> It might also be a good idea that any SIG that is going to be "official"
> has the requirement that they write up a state of the sig every month or
> two with what's done, what's happening, what's next, and what's
> challenging. At a project the scale of OpenStack one of the biggest
> issues is actually having a good grasp on the wide range of efforts, and
> these summaries by teams are pretty critical to increasing the shared
> understanding.

++

Previously in the thread, we mentioned the need to clean up if SIGs are
no longer alive -- that regular reporting could be a good indicator of
liveness.

-- 
Thierry Carrez (ttx)

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

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

2017-06-27 Thread Sean Dague 
On 06/21/2017 01:10 PM, Michał Jastrzębski wrote:
> 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.

I think this is a key point. The simpler tools that github has, which
require that you build a workflow based on tags outside of the tools,
actually enables the effectiveness here.

Does k8s community currently have the same level of operators that
aren't developers participating as OpenStack?

I wonder if we're going down this path, if some kind of tooling like
standard tags for issues/patches should be added to the mix to help gain
the effectiveness that the k8s team seems to have here.

I also think it's fine to rebrand WG to SIG, but we should also be
honest that it's mostly a rebrand to consolidate on terminology that k8s
and cncf have used that people find easier to understand so it's a way
in which openstack is not different than those. Consolidating on terms
isn't a bad thing, but it's really a minor part of the workflow issue.

It might also be a good idea that any SIG that is going to be "official"
has the requirement that they write up a state of the sig every month or
two with what's done, what's happening, what's next, and what's
challenging. At a project the scale of OpenStack one of the biggest
issues is actually having a good grasp on the wide range of efforts, and
these summaries by teams are pretty critical to increasing the shared
understanding.

-Sean

-- 
Sean Dague
http://dague.net

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

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

2017-06-26 Thread Melvin Hillsman 
On Wed, Jun 21, 2017 at 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 > > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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 th

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

2017-06-22 Thread gordon chung 


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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-06-21 Thread Zhipeng Huang 
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  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
> >> mailto:thie...@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)
> >>
> >>
> >> 
> __
> >> O

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

2017-06-21 Thread Lance Bragstad 


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
>> mailto:thie...@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-requ...@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-requ...@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 tha

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

2017-06-21 Thread Michał Jastrzębski 
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  wrote:
> On 6/21/2017 11:17 AM, Shamail Tahir wrote:
>>
>>
>>
>> On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez > > 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-requ...@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-requ...@lists.openstac

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

2017-06-21 Thread Matt Riedemann 

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



On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez > 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-requ...@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-requ...@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

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

2017-06-21 Thread Shamail Tahir 
On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez 
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-06-21 Thread Thierry Carrez 
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-06-21 Thread Shamail Tahir 
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 
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-06-21 Thread Thierry Carrez 
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-06-21 Thread Matt Riedemann 

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-06-21 Thread Thierry Carrez 
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev