[openstack-dev] [tc] campaign question: How "active" should the TC be?

Doug Hellmann doug at doughellmann.com
Mon Apr 23 14:35:32 UTC 2018


Excerpts from Zhipeng Huang's message of 2018-04-23 21:50:15 +0800:
> In general I would prefer TC take an active role regarding exploring new
> use cases and technology directions leverage the existing OpenStack
> infrastructure. I would against TC being too active on project level
> governance.

This would be a new area for the TC to consider. Can you elaborate a bit
on what you think we would need to change in order to support that, and
why the TC is the best place to do it (rather than one of our other
team-based structures like a project team or SIG)?

> 
> For example we have been discussing about edge computing recently and we
> don't have any idea on how a lightweight OpenStack should look like: maybe
> no scheduling since edge is more about provisioning ? maybe a Rust
> implementation of this lightweight version of OpenStack ? There are so many
> interesting new things that yet to be explored and should be championed by
> the TC.
> 
> However regarding issues like how a project should govern itself, it is
> better for TC to reactive and let project team driven its own structure. I
> can't think of there is any concrete example on this matter now since TC
> has been doing rather well on this matter , but I guess this could be a
> precautious action :)
> 
> On Mon, Apr 23, 2018 at 9:35 PM, Doug Hellmann <doug at doughellmann.com>
> wrote:
> 
> > Excerpts from Doug Hellmann's message of 2018-04-23 09:27:09 -0400:
> > > [This is meant to be one of (I hope) several conversation-provoking
> > > questions directed at prospective TC members to help the community
> > > understand their positions before considering how to vote in the
> > > ongoing election.]
> > >
> > > We frequently have discussions about whether the TC is active enough,
> > > in terms of driving new policies, technology choices, and other
> > > issues that affect the entire community.
> > >
> > > Please describe one case where we were either active or reactive
> > > and how that was shown to be the right choice over time.
> > >
> > > Please describe another case where the choice to be active or
> > > reactive ended up being the wrong choice.
> > >
> > > If you think the TC should tend to be more active in driving change
> > > than it is today, please describe the changes (policy, culture,
> > > etc.) you think would need to be made to do that effectively (not
> > > which policies you want us to be more active on, but *how* to
> > > organize the TC to be more active and have that work within the
> > > community culture).
> > >
> > > If you think the TC should tend to be less active in driving change
> > > overall, please describe what policies you think the TC should be
> > > taking an active role in implementing.
> > >
> > > Doug
> >
> > There was a question from ttx on IRC [1] about my use of the terms
> > "active" and "reactive" here. I mean active as "going out there and
> > doing things and anticipating issues" and reactive as "dealing with
> > things as they come up and aren't resolved in another way".
> >
> > Doug
> >
> > [1]
> > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%
> > 23openstack-tc.2018-04-23.log.html
> >
> > __________________________________________________________________________
> > 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
> >
> 
> 
> 
> -- 
> 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



More information about the OpenStack-dev mailing list