to put my public cloud wg hat on, I think the lack of coordination is a common problems among OpenStack WGs but I think transitioning WGs to SIGs will help solving the issue alone.
I think from my observations from existing WGs, the mechanism that are now in place works great, we have many productive output coming out of WGs. The core problem here is how WG chairs establish a working method with PTLs of related project each cycle, so that both side understand each other and important matters getting solved in the near cycles. The dev circles and non-dev circles are fairly isolated at the moment. Merely rebranding WGs won't solve this core problem, I would recommend the following actions: 1. In addition to the current TC/UC/Projects/WG mechanism, allow people to establish adhoc SIGs without any procedure overhead (getting approved by any entity). Folks in the spontaneously established SIGs could find their best way to get their requirement done. We could have an overall wiki page for collection/registration of all the SIGs created. 2. Enhance dev/non-dev comms. I doubt more meetings will be the solution. a. I would suggest projects when doing their planning at Forum or PTG, always leave a spot for requirement from WGs. And WG chairs should participate this dev meetings if their WG has done related work. b. Moreover the foundation could start promotion of project/WG collaboration best practices, or even specify in the release document that certain feature are based upon feedback from a certain WGs. c. WG should have cycle-based releases of works so that they got a sense of timing, no lost in a permanent discussion mode for issues. My 2 cents On Thu, Jun 22, 2017 at 1:33 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > > > On 06/21/2017 11:55 AM, Matt Riedemann 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: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. > > I was just going to say the policy efforts sound like a great candidate > for a SIG. We held off on making it a working group until there was a > need for it. We hold a weekly meeting but it'd be nice to get more > involvement from project managers, operators, products, etc. But, like > Matt said, I'm not sure how to encourage that involvement outside of > methods we've already tried. > > > > > 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. > > > > > > __________________________________________________________________________ > 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 > > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__________________________________________________________________________ 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
