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

Michał Jastrzębski inc007 at gmail.com
Wed Jun 21 17:10:48 UTC 2017


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



More information about the OpenStack-dev mailing list