On Mon, Oct 3, 2016 at 9:30 AM, gordon chung <g...@live.ca> wrote: > hi, > > as there are many candidates this TC election, i figured i'd ask a > question to better understand the candidates from the usual sales pitch > in self-nominations. hopefully, this will give some insights into the > candidates for those who haven't voted yet. obviously, the following is > completely optional. :) > > i initially asked this to John Dickinson[1] in his self-nomination. i'd > like to open this up to everyone. the (re-worded) question is: > > the TC has historically been a reactive council that lets others ask for > change and acts as the final approver. do you believe the TC should be a > proactive committee that initiates change and if yes, to what scope? > more generally, what are some specific issues you'd like the TC address > in the coming year? > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2016- > September/104821.html > > thanks, > -- > gord > __________________________________________________________________________ > 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 > Hey Gordon,
It's my opinion that OpenStack and the community has grown and changed so much over the years that now it might be beneficial for the committee to be more "proactive" as you put it and perhaps drive things. There's a few very big problems with that statement though, the first of course is "proactive about what"? If it's things like driving projects to actually do what they advertise I think that's fine. Picking some project-wide effort (I'm looking at you Python 3) that's awesome. On the other hand if it's things like trying to be the only source of innovation or new ideas... well that would be pretty awful in my opinion. The other big problem (and probably the most significant) is that what some folks are talking about here is not really what the TC was ever designed or intended for. The TC in my opinion has over the last several years done EXACTLY what it was designed, intended and meant to do. I think we've been really fortunate to have some really great people serve over the years and do the work. So regardless of what anyone says they "will or won't do" the fact is, there needs to be some consensus and some work to really figure out how (or even if) we want the TC to evolve, and if so, then evolve how. So the first thing for the TC to do during the next release in my opinion is; try and figure out how they can best serve the community? How can they add the most value? It may turn out that the way to do those things is to keep doing things exactly as they have been, or maybe there are some things we can drill into and try and take more of a driving or pro-active approach to. Personally, as I said in my nomination email, I would like to push to have some oversight on making sure that the various services in OpenStack actually "work". That means that I can install them based on the documentation they provide, get them up and running and use them to do something useful and they should be relatively stable. Anyway, hope that helps a bit. Thanks, John
__________________________________________________________________________ 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
