Re: [openstack-dev] [tc] open question to the candidates

[gordon chung]

hi,

just so it doesn't seem like you're replying to nobody. i want to thank 
all of you for opening up on this topic which hopefully isn't only 
important to me alone. it really helped me with my voting beyond the 
people i know.

i apologise if this was a polarising topic but it was great to see 
everyone's opinion on what the role of the TC is. there was a diverse 
set of answers so it should be fun trying to come to a consensus on 
everything when all is said and done. that said, it seems like the main 
commonality was y'all have optimism/passion in what you're targeting.

all the best in the election. everyone else, go vote!

for those who didn't reply but want to, i'm still interested. i feel 
like this could be asked to non-candidates too as what they expect but i 
don't know if ML is best medium for that.

cheers,
-- 
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

Re: [openstack-dev] [tc] open question to the candidates

[Amrith Kumar]

Gordon,

You also asked for specific examples of things that candidates would like the 
TC to address in the coming year and I missed that.

Over the past several months there have been several independent threads that 
have called into question the 'leadership' that the TC has brought. There have 
been voices on both sides of this; the voices that say the TC doesn't do 
enough, and (when the TC does) voices that say the TC does too much. This is 
clearly a contentious area, but one that needs some attention.

I am therefore heartened that the TC did take the positive step of trying to 
gets its membership to attend a training session (and I was lucky to be able to 
attend that as well) and try and understand how the TC should lead. The model 
of leadership (Stewardship/Servant Leadership) is one that is well suited to 
the particular situation that the TC finds itself in. So item #1 on the list of 
things that I'd like the TC to take up as a priority in the next year is to 
further understand this model of leadership and make specific changes to the 
way(s) in which it does things to better serve the community; that is the very 
essence of Stewardship.

I'll also put in a shameless plug for a session[1] at Barcelona that I'll be 
moderating; Monty, Thierry, Colette Alexander and Doug Hellmann will be the 
panelists and we will be talking about this. 

The second thing that I would like the TC to actively advance is something that 
Doug Hellmann proposed recently, the notion of project wide series goals. I 
believe that it is one aspect of making OpenStack more cohesive, and better and 
easier for deployers and end users. Usability by deployers and end users has 
been a frequent complaint about OpenStack and I think this initiative will go a 
long way to improving that. The discussions around the idea (that I expected 
would be relatively non-controversial) regarding python is a microcosm of the 
kind(s) of challenges that come with leading a diverse community and I think 
improvements on the leadership model (above) will help drive these common and 
broad based improvements across OpenStack, things that are sorely needed if we 
don't want OpenStack to fragment into a number of disjointed projects.

As I was reading news on my RSS Feed yesterday, I happened upon a question "Do 
I need to install a installation of a sump pump?" I kid you not. When I clicked 
on the link, the question appeared to have been deleted. But there was a 
fleeting moment when I felt that I had missed the announcement of a new 
OpenStack project "sump pump". The big tent is a great thing, it did much of 
what it was intended to do but I'm not sure that the end result was completely 
predicted. I have some reservations about the end result of the Big Tent from 
the perspective of end-users and deployers.

Which brings me to the third thing, I believe that the TC must lead the 
discussion of "What is OpenStack" and I realize that there are those who 
believe that it is a single 'product' and those that feel that it is a loose 
federation of projects. In the conversation I have heard much of what OpenStack 
"never was" from people who have been associated with OpenStack from the time 
when it was 3 lines of code or during the first meetings that discussed it. 
Well, this is now six or more years later, and it is possible that the time has 
come for OpenStack to change.

In the department of things that I'd like the TC to do proactively, I see "big 
things", things which set vision, things that set the course, things that set 
the overall direction of OpenStack.

Sorry for missing this part of the question the first time around, and thanks 
for asking this question. I hope that in future election cycles we can have 
this conversation in a more robust way, and potentially not in a format that is 
squeezed for time.

Thanks,

-amrith

[1] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15243/stewardship-bringing-more-leadership-and-vision-to-openstack


> -Original Message-
> From: Amrith Kumar [mailto:amr...@tesora.com]
> Sent: Monday, October 03, 2016 12:33 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tc] open question to the candidates
> 
> 
> 
> > -Original Message-
> > From: gordon chung [mailto:g...@live.ca]
> > Sent: Monday, October 03, 2016 11:31 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [tc] open question to the candidates
> >
> > 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. obvio

Re: [openstack-dev] [tc] open question to the candidates

[Sean Dague]

On 10/03/2016 11:30 AM, gordon chung 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,
> 

Does a committee initiate change? or do dedicated individuals? I feel
like there are a ton of dedicated individuals within our community (many
on the TC, but 13 slots is not enough to cover how many dedicated folks
there are). They are constantly doing hard and good work to make our
community move forward.

I feel like the role of the TC, as a group that votes and controls the
governance, is mostly about making sure that all these really great
efforts aren't negatively impacting the long term viability of the
OpenStack community. The TC really is stewards of that community. The
community is what produces the software we have, supports our users, and
helps mentor folks into the environment.

There is tons of work to be done in Open Stack. Probably 80% of it is
non controversial. I often feel like the implicit part of the ask is
that the energy of the folks on the TC is spent on the most
controversial 5%, where our plurality shows, and we as a community are
not of one mind. It assumes that where we disagree is the most important
parts of how the community moves forward. But that's often not true.
Often the thing holding us back isn't that, it's other things where we
see folks struggling.

A couple of good instances that I've been involved in are things like
the devstack plugin interface, where lots of projects needed to build
their own custom full stack environments, way more than devstack code
support in tree. A few of us identified the friction, came up with a
solution, brought it to the community. The same with the recent API ref
effort. There was huge friction around API documentation, that meant our
users basically had to read our source code to write an application. At
which point the API is nearly pointless. A couple of us (2 from the TC)
identified the issue, spitballed options, figured out a path forward.
And it's been a huge success.

Now, people may say, those don't sound like giant strategic sweeping
direction changes. And they aren't. We we have to be careful not to
assume that flashy controversial work is the most important work to be
done. We're trying to building an ecosystem here. And an ecosystem isn't
just pretty flowers, and juicy tomatoes. It's grubs, and dirt, and
compost, and weeds, and worms, and bees, and lots of hard work creating
fertile soil to get the best results.

Ok, so there are still controversial issues, which we do need to have a
way through. Handling those kind of issues requires trust and the
benefit of the doubt. At times, recently, it doesn't feel like we have
enough of it. One thought I have had about moving us forward is to take
some time this next cycle on visions of OpenStack. Not a top down
version of this, but a TC led exercise where we get lots of people in
our community to write down their visions, and feel safe doing it. This
was really how we got to the Big Tent. At the time there was a bit of
deriding about "all the blogs" where people were expressing themselves.
But it was a really useful exercise, because you got lots of
perspectives out there. And, it turns out, they agreed on about 80% of
the changes we needed, and where we didn't agree we were able to move
forward knowing we were looking at shades of the same thing.

Maybe I'm overly optimistic there, but we as a community also need to
realize the amazing thing that we've built so far. And the fact that
we've build a community that is going strong, despite many of the
founding members having moved on.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [tc] open question to the candidates

[John Griffith]

On Mon, Oct 3, 2016 at 9:30 AM, gordon chung  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

Re: [openstack-dev] [tc] open question to the candidates

[Jeremy Stanley]

On 2016-10-03 15:30:56 + (+), gordon chung wrote:
[...]
> 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?

I view the TC as both a technical body to which individuals can
request input on OpenStack-wide concerns or appeal decisions made in
an individual project with implications on the community as a whole,
and also a force for change with a tempered view of OpenStack's
overall direction along with perspective on our community's
strengths and weaknesses. The only direct control the TC is able to
exercise in this regard is addition/removal of governance tags and
inclusion/exclusion of official ("big tent") status for teams.
Fortunately, as elected representatives of our community the
opinions of the TC carry weight with decision-makers throughout not
only individual project teams, but also the OpenStack Foundation
Board of Directors and employees in many member companies.

> more generally, what are some specific issues you'd like the TC address
> in the coming year?
[...]

Out of fairness I've avoided reading any other candidates' responses
yet, so forgive me if I end up repeating points they've also made.

Similar to the sitting TC, I agree general leadership tasks such as
improving cross-project collaboration among developers or recording
previous assumptions based on the community's oral tradition (so we
can all reconcile, evaluate and even disagree with and subsequently
improve those) are important, as are specific initiatives like our
much-overdue Py3K support or API consistency. Per my platform
statement, I also believe increasing solidarity between OpenStack
and the rest of the greater free software community is critical, and
so is ensuring ease of involvement and contribution from
unaffiliated volunteers, distro package maintainers and our end
users and operator/deployers. Another thing I'd love to see is the
TC weighing in more actively on software freedom concerns, for
example encouraging driver support in official projects to embody
the spirit of our license choice rather than merely the letter of
that license.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [tc] open question to the candidates

[Clark Boylan]

On Mon, Oct 3, 2016, at 08:30 AM, gordon chung wrote:
> 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?

Yes, I think the TC should be a proactive committee. I think the
OpenStack wide goals work has been a good push towards being more
proactive. As for scope I believe the current process of soliciting
feedback from the community then picking a small number of achievable
goals to focus on per release cycle is a good place to start. Chances
are it won't be perfect, but if we don't try something progress can't be
made. Then in a cycle look back on what worked and what didn't and
refine the process.

Ideally OpenStack wide goals should affect the breadth of our projects
and users. Specifically goals like becoming python 3 compatible and
testing on python 3 are great. CPython 2 has a limited lifetime and
OpenStack (not just Nova, Glance, etc) needs to be planning ahead to
deal with this. It isn't something that can happen overnight and we
should agree on a common plan to address this so that we don't end up
with some projects doing Python 3 and others doing PyPy* to the
detriment of our developers and users.

Another example of a place where project wide goals make sense is in
ensuring that OpenStack runs and is tested on newer distro releases as
they become available. OpenStack isn't deployed in a vacuum and we
should do what we can to make sure that the barriers to deployment don't
begin at "can't deploy OpenStack on the distro most people are trying to
deploy OpenStack on". In the past we have done a reasonable job at
uplifting OpenStack onto new distro releases and making sure the tests
run properly. The recent Trusty to Xenial transition has been somewhat
painful though. Part of that is probably my fault, but we should stop
expecting magical gnomes to do all the work for OpenStack and call it
out as an explicit goal in the future for all of OpenStack.

As a user of OpenStack clouds I would also like to see more push for a
consistent experience as presented to our end users. Tons of work has
been done to make this much better than it was a few years ago, but
there is so much more we can do. It would make me so happy if we could
make OpenStack useable without knowledge of the underlying cloud
implementation choices. This actually ends up being problematic due to
many small issues so I am not sure if this makes sense as an OpenStack
wide goal, but it should illustrate the level at which I think the TC
should be proactive.

* I have nothing against PyPy and this shouldn't be interpreted as an
argument against using it beyond CPython 2's end of life, but I think
that we need to solve large scale problems like this consistently so
that developers, operators, and our users don't have to juggle a half
dozen toolsets to get anything done with OpenStack.

Hope this helps,
Clark

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Doug Hellmann]

Excerpts from John Dickinson's message of 2016-10-03 14:26:00 -0700:
> 
> On 3 Oct 2016, at 12:31, Doug Hellmann wrote:
> >
> > I think that's the balance we want to
> > have: listen to input, collect information, then clearly set the
> > direction without over-prescribing the implementation.
> 
> In light of this statement, would you reevaluate previous decisions you've 
> made regarding implementation details? You've criticized OpenStack projects 
> for not using certain code, you've advocated for openstack-wide goals which 
> are all about implementation[1], and you voted against Swift and other 
> projects using Golang for an internal process[2]. Each of these are quite 
> prescriptive with regards to the implementation. Would you change your vote 
> on any of these decisions if you are reelected?
> 
> [1] https://review.openstack.org/#/c/349068/
> [2] 
> http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html

I said "without *over-prescribing*", not "without prescribing at
all". I generally don't care how the goal is achieved, as long as
it is. That's why the goals framework focuses on describing end-states,
and not procedures or "specs".

Yes, sometimes I will advocate for goals that involve implementation
details of projects.  Probably a lot of the time, actually, since
most of the goals we've discussed so far are related to doing things
consistently (if you're interested in the other goals being discussed,
there's an etherpad [3]). I want projects to use common tools and
implementation patterns as much as possible, because doing so
benefits our users, makes life easier for our contributors, and
enables cross-project efforts like infrastructure, documentation,
and release management. Common tools and patterns also contribute
to our sense of being one community that is working on one over-arching
project.

Taking the two specific goals discussed over the past few months:

The Python 3 goal is about running tests under Python 3 as well as
Python 3. I don't care what order or process projects follow to get
their tests running under Python 3. I do want them to do it, and I
do want them to get *all* of the tests running.

The Oslo cleanup goal is related to dealing with unsupported code
lingering in projects.  Projects should either remove unsupported
code in favor of supported code, or declare that they will support
the "forked" modules themselves by moving them out of a common
directory that implies they are supported by the Oslo team. Either
way we convert to using supported code and satisfy the goal.

Regarding Golang, I tried to explain my position to you at OpenStack
Days East a few weeks ago, but apparently I wasn't as clear as I
thought.  I have to look beyond the Swift team's immediate needs
and consider our entire community.  With that in mind, I did not
reject the use of Golang outright or permanently. I voted against
the Swift team's current request to be the first team to use it,
and in effect establish the standards for its use, based on the
team's continual resistance to adopting community standards.  Anyone
interested in the full statement I made at the time should read the
pastebin [4] as well as the meeting logs.

When the two of us talked about this in person, I tried to express
to you that I will reconsider my vote when the Swift team demonstrates
that it has revised its stance and begins participating in community
standards to the extent that I believe they would be good stewards
of the infrastructure needed to allow teams *besides themselves*
to use Golang.  If I am not mistaken, recently the team has done
some work to start incorporating reno, and I count that as a good
step.

If another team demonstrates a need to use a language other than
Python, I will consider their request separately and on its own
merits, regardless of the language.

Doug

[3] https://etherpad.openstack.org/p/community-goals
[4] http://paste.openstack.org/show/545744/

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Chris Dent]

On Mon, 3 Oct 2016, gordon chung wrote:


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?


I ended up getting overly excited in my response to Clay and answering
over there. So by the power of hypertext:

http://lists.openstack.org/pipermail/openstack-dev/2016-October/105000.html

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [tc] open question to the candidates

[John Dickinson]

On 3 Oct 2016, at 12:31, Doug Hellmann wrote:
>
> I think that's the balance we want to
> have: listen to input, collect information, then clearly set the
> direction without over-prescribing the implementation.

In light of this statement, would you reevaluate previous decisions you've made 
regarding implementation details? You've criticized OpenStack projects for not 
using certain code, you've advocated for openstack-wide goals which are all 
about implementation[1], and you voted against Swift and other projects using 
Golang for an internal process[2]. Each of these are quite prescriptive with 
regards to the implementation. Would you change your vote on any of these 
decisions if you are reelected?

[1] https://review.openstack.org/#/c/349068/
[2] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [tc] open question to the candidates

[Jim Rollenhagen]

On Mon, Oct 3, 2016 at 11:30 AM, gordon chung  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?

I believe I addressed this in my candidacy email, but for posterity I'll
talk about it a bit more here.

I believe that the TC will always need to be reactive to some extent,
however it should also strive to be more proactive than it currently is.

The big tent is a good thing IMO, but needs some work. Many projects
struggle with finding the common ways to do OpenStack-y things
(upgrades, microversions, integration testing, etc), and I think the TC
should work to make that easier. Most (all?) of the current and
nominated TC members know how to code, and (hopefully, heh) all
of them are familiar with how OpenStack works. They should use their
skills and knowledge to help projects become part of a coherent
OpenStack - building common tools and frameworks that projects
can adopt to be more like other projects.

tl;dr we assert OpenStack is "one framework of collaborating components",
and not "a loose connection of disconnected projects".[0] From the outside,
it doesn't always look like that. The TC should work to help fix that.

// jim

[0] http://governance.openstack.org/reference/principles.html#one-openstack

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Doug Hellmann]

Excerpts from gordon chung's message of 2016-10-03 15:30:56 +:
> 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 for raising this question, Gordon.

I hope it is clear from my pushing the goals initiative [2] this
cycle that I want the TC to be a bit more active than it has been
in encouraging project teams to take specific action so the whole
project is moving in common direction. On the other hand, the process
for selecting those goals is intended to incorporate a lot of input
from the community and it could also characterized as "reactive"
to what the community wants. I think that's the balance we want to
have: listen to input, collect information, then clearly set the
direction without over-prescribing the implementation.

Doug

[2] http://governance.openstack.org/goals/index.html

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Joshua Harlow]

gordon chung 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,


What a neat question!

So to me there is a middle-ground here between a fully proactive 
committee and a reactive one. I believe it has gone a little to far to 
the reactive side and I would like to have it move more toward the 
proactive side (obviously not all the way to proactive, this isn't a 
dictatorship).


The scope I would like is for the TC to be a body that helps advocate 
the larger picture of where the community wants to be in 2-5 years and 
being proactively trying to help make that happen. That could involve 
reaching out to other communities and working with the technical 
leadership in those other communities (for example the CNCF @ 
http://cncf.io/ who is working with these folks?). It should also 
involve working with-in our own community to try to understand what the 
2-5 year vision really is (because honestly what is it?); and working 
through the writing of that down, the dissemination of it and working 
with folks that don't (or may not) agree with it.


In general I'd really like for folks on the TC to be leaders that can 
help proactively guide the rest of the community forward... I don't 
quite know the full scope of such guidance, but I feel it is a missing 
component the community hasn't ever quite figured out to well (but I 
still have hope!).


-Josh

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Amrith Kumar]

> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, October 03, 2016 11:31 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [tc] open question to the candidates
> 
> 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?

[amrith] Gordon, great question. Short answer is that I believe that the TC 
should be proactive. All the members in the TC are themselves active 
contributors to different parts of OpenStack and there is a reasonable 
expectation that they are remaining informed about the things that are going on 
in all projects, are aware of what deployers and users are trying to do with 
OpenStack and the problems they are facing.

I believe that this gives them the ideal position to not only react to issues 
that come up, but also in cases take proactive steps to improve things. But, in 
keeping with the openness of OpenStack, I believe that any 'proactive' action 
should be discussed in the open and decided only after this open participatory 
process.

In the future it may be a good idea to have an IRC meeting where all candidates 
attend and members of the community get to participate in a moderated 
discussion. This may mean that the timeline (closing deadline, polling) may 
need to be altered but I think an opportunity for all candidates to discuss 
these kinds of things would be valuable.

Thanks!

> 
> [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

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Sean McGinnis]

On Mon, Oct 03, 2016 at 03:30:56PM +, gordon chung wrote:
> 
> 
> 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?
> 

This is an interesting question.

Leadership in an open source project really is a unique and interesting
thing. In a lot of ways you have little control over what is proposed
and focused on other then to suggest things you think are important and
hope that others agree. On the other hand, you need to apply some
control over what is allowed in to make sure it is good and what is
right for the project.

I see the TC, like being a PTL, as needing to straddle this line of
being there to foster and encourage, while also needing to be the final
say and being the enforcer when things that are not seen as right for
OpenStack as a whole.

The "committee" part of the TC is key here I think. This is not a
dictatorship, and no one person should have absolute say over what is
and is not acceptable. We need a diverse group of people, with the best
interests of the project in mind, to be able to discuss issues and
disagreements.

To directly answer the question - both. The TC needs to be looking at
the landscape and getting the bigger picture to help influence where we
are going. But there is also no avoiding being somewhat reactive. There
will always be new things and ideas popping up that will require a
reactive stance. If someone wants to propose using the D language to
implement some new project, the reasons for that choice need to be
evaluated to tell why and determine if it makes sense as far as the
overall project goes.

One thing I would like to see in the coming year is moving beyond the
required reactive aspect and reaching out more to users and operators to
learn more about what they need. What issues are they running into? If
they stopped using OpenStack, why? I think it's important that we
recognize OpenStack-wide what's missing or what's a problem and start
working with the various project teams to get some of these gaps and
shortcomings addressed.

Sean (smcginnis)

> [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

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Edward Leafe]

On Oct 3, 2016, at 10:30 AM, gordon chung  wrote:

> 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?

OK, I'm going to start with the standard cop-out answer: "It depends"

What I mean is that one of the duties of the TC is to be reactive: to act as a 
referee when there are issues brought to it. This can't and shouldn't change.

But I *would* like to see some more pro-active work, primarily in the area of 
technical matters. They are the "Technical" committee, after all. So while a 
heavy-handed, top-down approach is never going to work, there are areas where 
the TC must push all OpenStack projects forward. One area that they are already 
doing this is pushing projects to fully support Python 3. This is an essential 
technical matter, as Python 2 will be unsupported by 2020, and it is the TC's 
job to ensure that all of OpenStack is ready.

One other area where I would like to see the TC actively promote is in 
modernizing the architecture of the projects to keep up with the changes in the 
underlying technologies. Having been involved in the initial design decisions 
in 2010, I can state with certainty that had those same discussion been held in 
2016, we would have made very different choices. That's the nature of the world 
we operate in, and while change for the sake of change is a waste of time, 
change to keep OpenStack from becoming a outdated dinosaur is essential.

Tying those two points together brings me to a third: the expansion of 
languages used in OpenStack. We are and always have been a Python project. 
There were newer languages with some support by a few developers in the 
beginning, but as both Nova and Swift were Python, OpenStack was Python. And as 
things change, new languages will always come around that have some benefits 
that developers like. But experience tells me that every time you introduce a 
new language into the mix, you fracture the community. Yes, I know about 
Javascript in Horizon, but that's a particular case, as web browsers do not 
natively support Python. As long as we keep current with Python and its 
evolution, there is no good reason to fracture the development community within 
OpenStack. In the specific case of Swift and the use of Go, I wrote about my 
feelings here: http://blog.leafe.com/on_swift/ 

And thanks for posting this question. There is not nearly enough discussion 
when it comes to TC elections.

-- Ed Leafe






__
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

Re: [openstack-dev] [tc] open question to the candidates

[Clint Byrum]

Excerpts from gordon chung's message of 2016-10-03 15:30:56 +:
> 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?
> 

Great question Gordon. I sort of wish there was a little more time
between nomination and polls opening, since I'm sure many (myself
included) have just finished the extremely difficult task of ranking
these 21 fine individuals.

My answer is that purely reactive bodies aren't leaders, they're
roadblocks. You need only look at the current US legislative branch to
see an example of this.

But I would disagree that the group has been purely reactive. The
group has been extremely busy with things brought to them, but in their
responses to these issues, they have empowered and encouraged OpenStack
contributors(including themselves) to go out and start initiatives
outside the framework of TC voting to build consensus and communicate
directly with the rest of OpenStack.

The best example of this is The Big Tent. I don't think that was purely
reactive, and it wasn't just the TC that made it happen. Yes, it was
in response to an untenable TC process, but a purely reactive group
would simply band-aid the problem, or let it wend its way through the
beuracracy. Really at the first sign of trouble, the group's members
drafted proposals, debated the issues wit the community, and enacted a
system that, while certainly flawed, produces better results.

So, it may be a nuance, but I'd say the TC is _responsive_, not
_reactive_, and it will work best that way, because OpenStack is big,
and busy, and that doesn't seem to be changing any time soon.

__
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

Re: [openstack-dev] [tc] open question to the candidates

[Anita Kuno]

On 16-10-03 11:30 AM, gordon chung 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,


Thanks Gord:

My view of the technical committee is that it is in place to solve 
actual problems not to chase after things which may or may not be a 
problem. One of the best ways to identify if some issue is a problem is 
for someone to identify it is a problem for them. Issues have been 
raised by members of the community approaching the technical committee, 
issues have also been raised by technical committee members themselves.


Whether something is considered reactive or proactive is often based on 
their personal perception as events unfold. Sometimes some members feel 
something should be addressed but need the correct alignment of events 
to occur for the community to agree.


I think one of the largest issues we will face in the coming year is 
what does it mean now that the projects will be meeting at the project 
team gathering in Atlanta in February and the Conference will take place 
in Boston later in the spring. These events affect a lot of people and 
many folks will be confused about what can and can't be accomplished in 
the separate spaces and also the symbology of what this means to them, 
their work and their business plans. I think the Foundation has be 
proactive in communicating this. I think the technical committee to date 
has been proactive in recognizing this is a need. I think the next 
technical committee with have to do both proactive communicating and 
reactive redirecting as folks move toward these events, at these events 
and following up these events. I think these events are much on people's 
minds and the technical committee needs to continue to communicate the 
workflow and expectation of these events in concert with the Foundation 
as it has done thus far.


Thank you,
Anita.

__
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