Difference between revisions of "TC Elections October 2014"

Revision as of 17:14, 7 October 2014

TC Elections October 2014

Officials

• Anita Kuno (anteaya) anteaya at anteaya dot info
• Tristan Cacqueray (tristanC) tristan dot cacqueray at enovance dot com

Election System

Elections will be held using CIVS and a Condorcet algorithm (Schulze/Beatpath/CSSD variant). Any tie will be broken using Governance/TieBreaking.

Timeline

• October 3 - October 10, 05:59 UTC: Open candidacy for TC positions
• October 10 - October 17: TC elections

Elected Positions

Under the rules of the TC charter, we need to renew 6 TC seats for this election. Seats are valid for one-year terms.

• Technical Committee member - 6 positions

Electorate

The electorate for this election are the Foundation individual members that are also committers for one of the official programs projects over the Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26, 2014 05:59 UTC).

The electorate is requested to confirm their email address in gerrit, review.openstack.org > Settings > Contact Information > Preferred Email, prior to September 26, 2014 05:59 UTC so that the emailed ballots are mailed to the correct email address.

There is a resolution to the governance repo that all of the electorate is expected to follow: http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20140711-election-activities.rst.

Candidates

Any member of an election electorate can propose their candidacy for the same election (except the seven TC members who were elected for a one-year seat last April: Thierry Carrez, Jay Pipes, Vishvananda Ishaya, Michael Still, Jim Blair, Mark McClain, Devananda van der Veen). No nomination is required. They do so by sending an email to the openstack-dev@lists.openstack.org mailing-list, which the subject: "TC candidacy" by October 10, 05:59 UTC. The email can include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate.

Confirmed Candidates

• Anne Gentle
• Monty Taylor
• Zane Bitter

TC Election Questions

In order to help the electorate learn more about the candidates, a template of questions will be posted by September 26, 23:59 UTC on this wikipage for tc candidates to answer in their nomination email. As a way of encouraging voters, the election officials may take responses to the same question in candidate emails and compose a blog post in order to help voters inform themselves. Staying with a format of Question > Answer will facilitate this use of data should it be determined this is possible to do as well as helpful to voters.

These individual topics are selected to give a range of items for the electorate to compare candidates on similar issues. You are welcome to respond to the topic, to answer the question or to not respond. Your choice of response will be identified beside your name when the answers are organized by topic to help the electorate better understand individual candidates. This is the first time we are doing this so choices of where the responses are published might be decided after responses are received. Responses will be published on this wikipage by the electoral officials. Please include your responses in your candidate announcement email in a clearly defined section so the electoral officials can copy/paste with confidence. There is no guarantee your formatting will be preserved.

Template

Topic: OpenStack Mission
How do you feel the technical community is doing in meeting the OpenStack Mission?

Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the technical committee mission?

Topic: Contributor Motivation
How would you characterize the various facets of contributor motivation?

Topic: Rate of Growth
There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate?

Topic: New Contributor Experience
How would you characterize the experience new contributors have currently?

Topic: Communication
How would you describe our current state of communication in the OpenStack community?

Topic: Relationship with the Foundation Board
The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?

Responses to TC Election Questions

Topic: OpenStack Mission: How do you feel the technical community is doing in meeting the OpenStack Mission?

Anne Gentle The technical community consists of a huge blend of people now, thank goodness, because the mission is a grand sweeping one for private and public clouds. Plus it has the word ubiquitous in it which makes it even more wide-reaching. We're making clouds for the planet and I feel we're tackling, blocking, clearing, and fighting hard to meet the Mission. We're struggling with the "simple to implement" but we have come a very long way.

Monty Taylor In case you haven't read it recently:

"to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable."

If there is anyone out there who feels we've nailed "simple to implement" I'd love to meet them. I think we've been focusing on all of the other parts - I'd like to see more attention placed on "simple to implement"

Zane Bitter (The mission is here, by the way: https://wiki.openstack.org/wiki/Main_Page just in case you don't have it committed to memory.)

I think we all have a lot of work to do on several fronts: - "simple to implement" and "massively scalable" in particular. But I'm very optimistic that work will get done because we have built a healthy, thriving community to do it.

Topic: Technical Committee Mission: How do you feel the technical committee is doing in meeting the technical committee mission?

Monty Taylor In case you haven't read it recently:

"The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project."

I think over the last year since we became all-elected, the TC has been doing a better and better job. Historically the TC has been a bit reluctant to own the words "technical leadership" Over the past cycle or two, the TC has consistently been stepping more up to the plate on this topic, and I think that trend needs to continue.

Zane Bitter (That one is here: https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)

I think the TC is doing a good job at encouraging the OpenStack ideals, but I think the size of the project as a whole has overwhelmed its capacity to provide _active_ technical leadership. We need to build up that capability.

Anne Gentle I feel the TC is supportive of the technical contributors to all the projects that make up OpenStack. We're constantly seeking ways to improve and challenge programs. We began to hold programs accountable for their integration. We pushed the limits of the definition of OpenStack by defining all code that a project maintains as part of OpenStack (defined sections). Yes, it was a defense on the side of our Active Technical Contributor community base, but it was a statement about our ideals - Openness, Transparency, Commonality, Integration, Quality.

Topic: Contributor Motivation: How would you characterize the various facets of contributor motivation?

Zane Bitter I wouldn't, but since you ask... OpenStack is not a hobbyist project. No major open source project is. The vast majority of contributors are able to contribute because it is benefiting their employer somehow - either because they have a problem to solve directly with OpenStack, or because they are selling something complementary to OpenStack. We need to make contributing as easy and pleasant as possible, so the first group will contribute at all and so the second group will contribute as much as possible in their long-term interests and not only in their short-term interests.

Anne Gentle Contributors are motivated in different ways, but we're all humans and behave like humans do. In Peter Kollock's study of online communities, he found these motivating factors for participating: reciprocity, reputation, sense of belonging, efficacy, and need. All of these make sense to me when put in the docs context, "why would anyone contribute to upstream documentation?" and I can also draw maps and correlations to the overall reasons why contributors work on upstream. We need to be aware of what happens when the "need" stems from corporate motivation, but I know that OpenStack is a great community to work within and that I can do my part to demonstrate which motivations I want to encourage in our community.

Monty Taylor I'm pretty sure the majority of our contributors are doing so as part of their jobs. I think this makes our dynamic a bit different than a "traditional" Open Source project.

That said - I think we see a very strong set of people who are passionate about what we're doing evidenced by the number of people who have worked for multiple companies while working on OpenStack.

I can't speak to everyone's motivation - but I can tell you what mine is.

Cloud is taking over as the way we think about how IT works. It's not an if, it's a when. But even with that, Cloud is an idea more than a destination. When we started, there was one legitimate definition for "Cloud" and it was Amazon. Amazon is a closed-source company run by a ruthless dictator. I do not want to live in a world where I need his permission to use a computer.

Over the last four years, we've made significant inroads in redefining what Cloud can be. Containers and bare-metal are now legitimate building blocks and I think it's becomming understood that you can use cloud to effectively run things other than scale-out ephemeral compute based patterns.

That direction and that transformation are the things that must happen for the Internet to keep both open and operational. I think it's essential that people make them happen. I'm lucky enough to be in a position where I can contribute to that - so I hack on OpenStack.

Topic: Rate of Growth: There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate?

Monty Taylor There are people who are core reviewers who I do not know. That's awesome.

Some of the consequences are that we have to continually reassess how we're doing things. I'm sure this drives people nuts - but we've reworked how we organize and govern ourselves several times as each previous system reaches a scaling point. The introduction of programs is an example of that - they were not needed in 2010, but in 2013 they solved a problem. It's possible that they, as an organizational structure have outlived their time, or it's possible that they still serve a purpose in helping us get our job done but need to be tweaked in scope. The big-tent-targetted-gate discussions point to fragility in our monolithic integration story - again caused by scale, and incidentally caused by us actually meeting and not shrinking away from the challenges of doing captive integration at scale.

Anne Gentle Hopefully by now you've seen me represent the cross-project ramifications of this growth rate over the years I've served on the TC. The docs program has had to adjust the expectations and educate incoming programs about how OpenStack documentation is not just project-by-project but an umbrella effort. People come to docs.openstack.org for OpenStack docs, not just nova or glance docs. I hope I have shown bravery in the face of the rate of growth and also pragmatism.

Zane Bitter The biggest and most important consequence is that we have lots of talented contributors working hard on solving real problems that our users have, and doing it in the open, the OpenStack way. Another is that we've outgrown some of the centralised shared resource structures that made sense in a smaller project. We'll need to work on decentralising and building communication paths.

Topic: New Contributor Experience: How would you characterize the experience new contributors have currently?

Anne Gentle As an admin for the GNOME Outreach Program for Women for the last two years, I have helped with on-boarding new interns who have to have a patch in order to complete their application. Really, though, the previous interns do a lion's share of the work in on-boarding newcomers to our community. I think this is because their eyes are freshest to the difficulties you'll encounter while figuring out our unique processes. I'm also amazed at how a wonderful small community has grown up out of helping others learn, and that's been the best part about seeing new contributors coming in. We've done a lot to make installing git review easier and specifically setting up the gerrit remote. So the very first on-boarding experiences can get better. Now, the experience of those of us a few years in isn't great either as reviews are harder and harder to get through and our gate is stuffed full with patches wanting in. I think we can work on both experiences at the same time to make it better for all contributors.

Zane Bitter I would have to guess frustrating. The process starts badly with a bunch of hoops to jump through culminating in the CLA. At least the first patch is greeted with a friendly, helpful "Welcome new contributor" message. From there we should keep in mind that the experience differs from project to project. The smaller ones are probably doing OK for the most part, but the larger ones are struggling to provide the timely feedback that new contributors need. In some cases that's exacerbated by overly-bureaucratic processes and review nitpicking (which could be summarised as a generally procedure-focused rather than results-focused outlook).

Monty Taylor OpenStack is optimized for high-throughput at the expense of individual patch latency. This means some of our processes may seem new or opaque to people depending on their background. However, given that the project has regularly doubled every six months for quite some time, I do not think solving this is a priority if it's at the expense of the productivity of the folks that breathe OpenStack 80 hours a week.

For those who have not begun contributing to another Open Source project in a while, I recommend you do so. EVERY project of size has its own quirks. Ours are, while long, well documented and consistent.

Topic: Communication: How would you describe our current state of communication in the OpenStack community?

Zane Bitter We communicate a lot, and in the open, which is great. The hard part is filtering the fire hose. As we decentralise even more, we'll need to mitigate that problem by establishing fixed (rather than ad hoc) channels of communication, so that people hear about the things they need to without getting swamped. The Oslo liaison program is one great example of how to achieve this.

Monty Taylor Did you read this email all the way to here? If so, communication is going well. :)

Inside of the tech community I think we're doing ok with communication. Piercing our bubble, on the other hand, needs work. Keeping up with what we're doing as an inside is hard enough, I cannot imagine trying to follow it as an outsider. Similarly, since we're optimized for intra-developer communication, getting a voice to operators and users is hard.

Anne Gentle Communication with such a wide, growing population can be difficult but I think we have the channels available with opt-in policies that make sense for our community. The TC listens on many channels, I know I'm subscribed to all the mailing lists without filters still, and we made a concentrated effort to write summary blog posts to let everyone (not just ATC listers) know what we're up to. We understand its importance and we have a lot of good writers and communicators on the TC who make communication a priority.

Topic: Relationship with the Foundation Board: The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?

Anne Gentle Our interactions with the Board include conference calls, in-person meetings, and IRC meetings. I personally find the in-person meetings valuable as it's easier to communicate in person with more rich feedback so you can get a sense of how the interaction is going. On IRC, there's a trade off in richness of input/output but there is also a precision in the typed phrasing, the ability to read back later while you have more thinking time, and an openness since anyone can read the interaction at any time. Our board has been quite solid and changed little over the years which has been helpful for building relationships over time. I know I can reach out to members and I have had members help me when I've asked for it. I sense we're all struggling with the growth rate and feeling like we can't be as agile as we used to. But we're all dedicated to an open cloud for all and I think that shared mission enhances our interactions.

Monty Taylor Abysmal, but getting better. We had a good TC/Board meeting in Atlanta and have another scheduled for Paris.

I think the biggest issue we face there is figuring out how to disagree with each other productively. It's essential that both the TC and the Board get better at being direct and open with each other when we feel that the other body is maybe not stepping up to the plate. There is information we learned from the board as part of DefCore that probably would have been better if it had just been some direct statements - and which I think once Rob and TC reps started meeting directly started getting worked out much more effectively. Similarly, the TC just passed a resolution requesting that the Board consider the DCO to be our CLA. It's clearly the board's prerogative to do whatever - but it's our responsibility to let them know that we have an opinion.

In short, we're learning how to work together being respectful of boundaries but still being honest about needs. It's a journey, and one I think is important that we take seriously.

Zane Bitter Getting the TC and the Board on the same page on any issue is a big challenge, because the combined group is *huge* (~30 people). Discussion inevitably moves slowly at that scale, and the Board doesn't tend to hold wide-ranging open discussions between meetings the way the TC does on openstack-dev. Cultivating relationships is important, but most of the work will continue to get done by joint subcommittees.