Open Stack

There is a not insignificant degree of irony in the fact that this
conversation has splintered so that anyone only reading openstack-operators
and/or user-committee is missing 90% of the picture.... Maybe I just need a
new ML management strategy.

I'd like to add a +1 to Sean's suggestion about WG/SIG/team/whatever tags
on reviews etc. This is something I've also suggested in the past:
http://lists.openstack.org/pipermail/user-committee/2016-October/001328.html.
My thinking at the time was that it would provide a tractable basis for
chairs to build standing discussion items around and help get more user &
ops eyes on blueprints/reviews/etc.

On 27 June 2017 at 10:25, Melvin Hillsman <mrhillsman at gmail.com> wrote:

>
>
> On Wed, Jun 21, 2017 at 11:55 AM, 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:un
>>> subscribe>
>>>     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.op
>>> enstack.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.
>>
>>
> A SIG possibly should continue to exist for something like scaling, as it
> will more than likely not have been created for a defined work dealing with
> scaling but rather scaling itself which a number of work items would come
> out of.
>
> 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.
>
>
> Part of the resolution SIGs can assist with in getting folks to attend,
> getting paid or not, are a number of outcomes from SIGs, well thought out
> feature requests (PjMs), understanding of what should/should not/can/can
> not be done (DEVs), why it makes sense to resolve one or more should/can
> nots (OPs), resources to speed time to resolution (PrMs), single point of
> discussion (ALL), etc, etc. Possibly when folks see that rather than
> spending 100% of their resources on a work item that load can be shared and
> there is a simple way to determine so by participating in a SIG that will
> help as well.
>
>
>>
>>
>> --
>>
>> Thanks,
>>
>> Matt
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> --
> Kind regards,
>
> Melvin Hillsman
> mrhillsman at gmail.com
> mobile: (832) 264-2646
>
> Learner | Ideation | Belief | Responsibility | Command
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>


-- 
Cheers,
~Blairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20170627/ff94cd9e/attachment.html>