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.
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.
--
Thanks,
Matt
__________________________________________________________________________
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