On Wed, Jun 21, 2017 at 11:55 AM, Matt Riedemann <mriede...@gmail.com> wrote:
> On 6/21/2017 11:17 AM, Shamail Tahir wrote: > >> >> >> On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez <thie...@openstack.org >> <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://openstack-dev-requ...@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-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 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -- Kind regards, Melvin Hillsman mrhills...@gmail.com mobile: (832) 264-2646 Learner | Ideation | Belief | Responsibility | Command
__________________________________________________________________________ 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
