Open Stack

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 <thierry at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170621/9e3bcabc/attachment.html>