Open Stack

On Wed, Jun 21, 2017 at 10:44 AM, Shamail Tahir <itzshamail at gmail.com>
wrote:

> 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]).
>
>
We currently have WGs that overlap for specific objectives - like
scalability - and having a Scalability SIG could be more efficient rather
than the objective existing in multiple WGs who still have to gather
resources to address the objective. Spin up/down would still happen though
a SIG would generally live longer, like UC teams, depending on the special
interest.



> 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.)
>

SIGs like Documentation, Public Cloud, Scalability, make sense rather than
being created to address a more specific objective. A WG could spin off
from a SIG but does not seem reasonable for it to be the other way around
since the idea behind a working group is to work on something specific -
AUC Recognition - and then those members fold back into 0 or 1 SIG. I could
be off but I get the feeling that WGs can come together and find
commonality amongst each other within a SIG and get more accomplished and
possibly quicker by aggregating resources around what they already share
interest in.


>
> Finally, how will this change impact the ATC/AUC status of the SIG members
> for voting rights in the TC/UC elections?
>
>
Possibly AUC could go to all members of the SIGs and ATC or extra-ATC is
provided as it does not seem fair, though fair may be irrelevant or
relative, for UC elections to be wholly subjected to all SIG members and
not TC elections. I think, Shamail correct me if I am wrong, under AUC
guidelines all SIG members would qualify?


> [1] https://drive.google.com/file/d/0B_yCSDGnhIbzS3V1b1lpZGp
> IaHBmc29SaUdiYzJtX21BWkl3/
>
> 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:unsubscrib
>> e
>> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646

Learner | Ideation | Belief | Responsibility | Command
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170622/6797ae3f/attachment.html>