Open Stack

seems like I forget to cc uc-ml. My reply to the dev-ml copied below:

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 not 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 Wed, Jun 21, 2017 at 11:11 PM, Melvin Hillsman <mrhillsman at gmail.com>
wrote:

> Hi everyone,
>
> One of the areas identified as a priority by the Board + TC + UC workshop
> in March was the need to better close the feedback loop and make unanswered
> requirements emerge. Part of the solution is to ensure that groups that
> look at specific use cases, or specific problem spaces within OpenStack get
> participation from a wide spectrum of roles, from pure operators of
> OpenStack clouds, to upstream developers, product managers, researchers,
> and every combination thereof. In the past year we reorganized the Design
> Summit event, so that the design / planning / feedback gathering part of it
> would be less dev- or ops-branded, to encourage participation of everyone
> in a neutral ground, based on the topic being discussed. That was just a
> first step.
>
> In OpenStack we have a number of "working groups", groups of people
> interested in discussing a given use case, or addressing a given problem
> space across all of OpenStack. Examples include the API working group, the
> Deployment working group, the Public clouds working group, the Telco/NFV
> working group, or the Scientific working group. However, for governance
> reasons, those are currently set up either as a User Committee working
> group[1], or a working group depending on the Technical Committee[2]. This
> branding of working groups artificially discourages participation from one
> side to the others group, for no specific reason. This needs to be fixed.
>
> We propose to take a page out of Kubernetes playbook and set up "SIGs"
> (special interest groups), that would be primarily defined by their mission
> (i.e. the use case / problem space the group wants to collectively
> address). Those SIGs would not be Ops SIGs or Dev SIGs, they would just be
> OpenStack SIGs. While possible some groups will lean more towards an
> operator or dev focus (based on their mission), it is important to
> encourage everyone to join in early and often. SIGs could be very easily
> set up, just by adding your group to a wiki page, defining the mission of
> the group, a contact point and details on meetings (if the group has any).
> No need for prior vetting by any governance body. The TC and UC would
> likely still clean up dead SIGs from the list, to keep it relevant and
> tidy. Since they are neither dev or ops, SIGs would not use the -dev or the
> -operators lists: they would use a specific ML (openstack-sigs ?) to hold
> their discussions without cross-posting, with appropriate subject tagging.
>
> Not everything would become a SIG. Upstream project teams would remain the
> same (although some of them, like Security, might turn into a SIG). Teams
> under the UC that are purely operator-facing (like the Ops Tags Team or the
> AUC recognition team) would likewise stay as UC subteams.
>
> Comments, thoughts ?
>
> [1] https://wiki.openstack.org/wiki/Governance/Foundation/
> UserCommittee#Working_Groups_and_Teams
> [2] https://wiki.openstack.org/wiki/Upstream_Working_Groups
>
> --
> Melvin Hillsman & Thierry Carrez
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng at huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh at uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20170622/6841e5fa/attachment.html>