Hi, 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? 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]).
The WGs could focus on defining key objectives for users of a shared group (market vertical like Enterprise or Scientific WG, horizontal function like PWG) and then SIGs could be created based on this list to accomplish the objective and spin-down. Similarly a project team could determine a need to gather additional data/requirements or need help with a certain task could also spin-up a SIG to accomplish it (e.g. updating an outdated docs set, discussion on a specific spec that needs to be more thoroughly crafted, etc.) Finally, how will this change impact the ATC/AUC status of the SIG members for voting rights in the TC/UC elections? [1] https://drive.google.com/file/d/0B_yCSDGnhIbzS3V1b1lpZGpIaHBmc29S aUdiYzJtX21BWkl3/ Thanks, Shamail On Wed, Jun 21, 2017 at 11:26 AM, Thierry Carrez <thie...@openstack.org> wrote: > Matt Riedemann wrote: > > How does the re-branding or re-categorization of these groups solve the > > actual feedback problem? If the problem is getting different people from > > different groups together, how does this solve that? For example, how do > > we get upstream developers aware of operator issues or product managers > > communicating their needs and feature priorities to the upstream > > developers? > > My hope is that specific developers interested in a given use case or a > given problem space would join the corresponding SIG and discuss with > operators in the same SIG. As an example, imagine an upstream developer > from CERN, able to join the Scientific SIG to discuss with operators and > users with Scientific/Academic needs of the feature gap, and group with > other like-minded developers to get that feature gap collectively > addressed. > > > No one can join all work groups or SIGs and be aware of all > > things at the same time, and actually have time to do anything else. > > Is the number of various work groups/SIGs a problem? > > I would not expect everyone to join every SIG. I would actually expect > most people to join 0 or 1 SIG. > > > Maybe what I'd need is an example of an existing problem case and how > > the new SIG model would fix that - concrete examples would be really > > appreciated when communicating suggested governance changes. > > > > For example, is there some feature/requirement/issue that one group has > > wanted implemented/fixed for a long time but another group isn't aware > > of it? How would SIGs fix that in a way that work groups haven't? > > Two examples: > > - the "API WG" was started by people on the UC side, listed as a UC > workgroup, and wasn't making much progress as it was missing devs. Now > it's been reborn as a TC workgroup, led by a couple of devs, and is > lacking app user input. Artificial barriers discourage people to join. > Let's just call all of them SIGs. > > - the "Public Cloud WG" tries to cover an extremely important use case > for all of OpenStack (we all need successful OpenStack public clouds). > However, so far I've hardly seen a developer joining, because it's seen > as an Ops group just trying to make requirements emerge. I want the few > developers that OVH or CityCloud or other public clouds are ready to > throw upstream to use the rebranded "Public Cloud SIG" as a rally point, > to coordinate their actions. Because if they try to affect upstream > separately, they won't go far, and we badly need them involved. > > Yes, it's mostly a rebranding exercise, but perception matters. > Hope this clarifies, > > -- > Thierry Carrez (ttx) > > __________________________________________________________________________ > 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 > -- 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