Re: [openstack-dev] [tc] open question to the candidates
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
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) > > 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
Re: [openstack-dev] [tc] open question to the candidates
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
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
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
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
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
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
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
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
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
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
> -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
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
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
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
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
[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? [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