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 <mrhills...@gmail.com> wrote: > > > 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: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-requ...@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-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > _______________________________________________ > User-committee mailing list > user-commit...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee > > -- 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