Open Stack

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: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: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 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:unsubscribe
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20170626/b08e48f8/attachment-0001.html>