TC Elections October 2014
- 1 TC Elections October 2014
- 2 Officials
- 3 Election System
- 4 Timeline
- 5 Elected Positions
- 6 Electorate
- 7 Candidates
- 8 Responses to TC Election Questions
- 8.1 Topic: OpenStack Mission: How do you feel the technical community is doing in meeting the OpenStack Mission?
- 8.2 Topic: Technical Committee Mission: How do you feel the technical committee is doing in meeting the technical committee mission?
- 8.3 Topic: Contributor Motivation: How would you characterize the various facets of contributor motivation?
- 8.4 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?
- 8.5 Topic: New Contributor Experience: How would you characterize the experience new contributors have currently?
- 8.6 Topic: Communication: How would you describe our current state of communication in the OpenStack community?
- 8.7 Topic: Relationship with the Foundation Board: The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?
TC Elections October 2014
- Anita Kuno (anteaya) anteaya at anteaya dot info
- Tristan Cacqueray (tristanC) tristan dot cacqueray at enovance dot com
Elections will be held using CIVS and a Condorcet algorithm (Schulze/Beatpath/CSSD variant). Any tie will be broken using Governance/TieBreaking.
- October 3 - October 10, 05:59 UTC: Open candidacy for TC positions
- October 10 - October 17: TC elections
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
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.
Any individual member of the foundation can propose their candidacy (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 email@example.com 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.
- Anne Gentle
- Monty Taylor
- Zane Bitter
- Dean Troyer
- Russell Bryant
- Doug Hellmann
- Adam Lawson
- Eoghan Glynn
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.
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.
Eoghan Glynn In all honesty, I would give us an A+ for effort, but more like a B- for execution. In our excitement and enthusiasm to add shiny new features, we sometimes take our eye off the ball in terms of what's needed to make the lives of our users easier. I'm as guilty of this as anyone else, perhaps even more so. But I think at this stage, it would be of much benefit to our user community if we swung the pendulum somewhat in the other direction, and shifted some focus onto easing the practical challenges of operating our stuff at scale.
Doug Hellmann I am amazed by what our community produces. We have some truly exceptional development teams building great software. We regularly add new components to the system, and our feature set is as diverse as the community. Our work is not perfect, but as we continue to refine it based on experience and input from users, we are continually improving the way we work and what we produce.
However, there are recurring themes in the user feedback after every release: We need to make OpenStack easier to operate, easier to use, and easier to debug. We are starting to build cross-project teams to work more directly on some of these areas, and it's important that we give priority to that work and consider usability and scalability as features.
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"
Adam Lawson *“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.”*
The whole point of mission statements is merely to identify what we are striving to achieve or accomplish within the organization. With that said, I feel that technical leadership is the first step to accomplishing a technical goal. So to that end, the existence of the TC is a positive first step. But it's just one step or many more to come. Within this particular TC cycle, I'd like to see the TC demonstrate leadership to drive a reduction of lingering technical debt and address API and module standardization. Openstack in its current form has a number of challenges that are affecting our ability to scale and while some of this can be solved organizationally, technical debt and standardization are challenges that will not be easy to resolve and might not even be 100 percent solvable within a single release cycle. But I look forward to how the TC *will* shepherd improvements to both process and the product and help drive the mission. On a side note, "easy to implement" is still just a goal and the engineering requirement to deploy and manage Openstack is still a prohibitive hurdle for many organizations. But we have more than one tool in front of us that will help us to help others who want to use Openstack but .. can't. That's something I'd really like to see change soon.
Dean Troyer I think the rapid growth in the number of incubated/integrated projects has diluted the TC focus and attention and it has become clear that ignoring the natural strata of OpenStack projects is not working.
Russell Bryant To recap, the mission statement is “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.”
“ubiquitous” - I think the part we’re doing great here. OpenStack is growing like crazy and is being used all over the place. The list of supporting companies  is impressive. The number and diversity of our contributors is even more impressive. With that said, we shouldn’t get comfortable. There is a lot more to go.
“public and private clouds” - I think we do a nice job working to support both of these use cases.
“regardless of size”, “massively scalable” - This one probably depends on who you ask. :-) Our scalability depends on the project. In some areas we’re doing great. In all areas, we have more improvements to make. I think our biggest failure here has been how well we communicate what to expect to the rest of the community. Some people expect that they can take every component of the integrated release to large public cloud scale. That isn’t true and we’ve done a poor job of setting expectations here. This is something I’d like to improve on.
“simple to implement” - I think OpenStack is far from simple. It’s also a large scale distributed system that is very incredibly flexible so it can support a large number of different use cases. So, we should set expectations accordingly. However, I still think there is a ton of room for usability improvements.
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?
Adam Lawson Has chosen not to respond to this topic.
Eoghan Glynn Well, to be honest, if I thought this couldn't be improved, I wouldn't be running for election.
On the one hand, I felt the gap analysis for already-integrated projects was a good and healthy thing, and certainly assisted in focusing resources over Juno on the areas where the TC saw deficiencies.
On the other hand, I was quite disheartened by how some of the TC discussions around project status played out. IMO there was a failure of due diligence and mentoring. If we continue to have the TC making important determinations about the future of projects (whether it be their integrated status or their "production readiness"), then I think we need to ensure that the TC keeps itself fully appraised from an earlier stage about the direction that the project is taking, and gives fair warning when it feels that a project needs a course-correction.
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.
Dean Troyer I think this and the previous question are intertwined at this point and it is time to do a sanity check on where we are and where we want to go. This conversation has started and there is no clear answer yet.
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.
Russell Bryant The TC mission statement can be found in the governance repository . The current version is: “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.”
The TC is only two years old. If you look through our history, I think the TC has done a nice job evolving processes and structure as OpenStack has grown. The next evolution of process and structure has been the most dominant area of discussion lately. I am very optimistic that we can resolve those issues.
The ways that we could improve our technical leadership have received a bit less discussion. As OpenStack grows into more and more projects, I feel that leadership around standardization becomes more and more important. I’d like to see the TC bootstrap an effort around APIs to help improve our consistency and overall quality. We are also discussing having a cross-project specs repository. It makes sense for the TC to own this to help provide more structure to development efforts that affect many projects.
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.
Doug Hellmann We're fulfilling most of the mission, but we can do better.
The Zaqar graduation discussion is a good example of an area where we need to rethink how we bring new project teams into OpenStack. There are several similar suggestions to drop our current incubation and integration process completely, and that is one option. Another is to set up the resources we would need to do an objective technical evaluation for projects. I favor a combination of those two ideas, evaluating projects on several criteria from the users' perspective, but deciding the "official" status of a team based on community considerations.
We have also recognized that we need some way to handle cross-project initiatives such as improving our logging to make debugging easier, but we do not yet have a formal structure in place to accomplish those goals. The way we set up working groups for those sorts of jobs is going to depend on the outcome of the bigger governance discussion, but I think they should be organized by the TC.
Topic: Contributor Motivation: How would you characterize the various facets of contributor motivation?
Adam Lawson I like what I read earlier today: "People want to do work that matters and enjoy doing it." This sums up Openstack contributors very well but it sums up a lot of us too though, doesn't it. Many of us are lucky enough to be able to work on Openstack full-time as a job. There are many others who work with Openstack in the context of Consumers, Users, Operators, Solutions Architects where it is not their full-time job but they participate with the Openstack community because of other reasons. Whatever the reason (philanthropy, my good looks), folks want to work on what matters and if it doesn't matter, there is no motivation to continue.
- I see friendly interactions within the community even when we disagree. That's motivating.
- I see members within the Openstack community soliciting and offering help to each other - even between companies who could technically be called competitors. That's motivating.
- I see the same people who earn a living on selling and supporting proprietary deployments of Openstack offering their assistance and perspectives to those who are not using their product and possibly never will. That's motivating.
The culture developed and nurtured by the Openstack community is nothing short of admirable and from someone who is socially-driven (despite my little shell), I have to say that so long as the TC adheres to and advances this culture, motivation will be easy to find for those who desire to get engaged.
For those who need a little help, I think the Upstream University is another place to encourage new contributors and get them motivated through empowerment via learning/knowledge and the satisfaction of watching their hard work being used and consumed by countless companies and individuals.
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.
Doug Hellmann I don't know if we have numbers, but my impression is that most of our contributions come from people employed at least in part to work on OpenStack. Their commitment to the project as a whole, outside of their area of specialty, varies for a lot of reasons. We want everyone to have a strong commitment to the whole project, but that's not always realistic, because it's not always up to the individual to decide how much time or effort they can put into working on OpenStack, or into a given area. That's perfectly normal and OK. We can, and do, welcome contributions from all sorts of people for all sorts of reasons.
Russell Bryant People want to do work that matters and enjoy doing it. OpenStack is clearly a project making a huge impact. We also need to make sure it’s a pleasant community to participate in. There are a lot of things that make some communities more enjoyable than others. There are obvious things we want to avoid that are covered by the community code of conduct . I think feeling non-productive hurts motivation. We need to keep working to identify and resolve issues that get in the way of getting work done.
Dean Troyer I think at a high level this is one of the motivations to re-evaluate our existing structure. We are a corporate-driven project and in spite of individual efforts to remain independent the corporate influence is being felt in ways that the individuals may have not anticipated, ie, being 'Integrated' is the most valuable attribute for a project, and is the indicator for investment for many corporate managers.
At an individual level I see people who want to make a better cloud and make the tools and components to get us there. We have some procedural things to smooth out (CLA, etc) and some significant scaling issues to address (review backlogs) in order to retain and utilize the energy being brought to OpenStack by new contributors.
Eoghan Glynn Most of my prior opensource experience was on various Apache projects and in contrast it's striking that the OpenStack contributor community is on the whole more skewed away from pure volunteerism, and towards corporate contributors. By that, I mean contributors who are employed by major operators and distributors of OpenStack, where their day-job is to go forth and make it better. On balance, this is actually a strength in our community. It certainly aids in the continuity and sustainability of effort. It also helps ensure that less glamorous, but ultra-important, efforts such as stable-maint and vulnerability management get the attention they deserve.
However, despite this skew, I'm well aware that we're building a "broad church" here. I think we all benefit from active efforts to build diversity in our contributor community and harness the energy of contributors with all kinds of motivations. Not just because it's the right-on thing to do, but because it's the *smart* thing to do ... ensuring that we get access to all of the talents, especially from previously under-represented groups. Towards this end, I continue to support the efforts of programs such as the GNOME OPW and their recent moves towards extending their reach to a wider set of contributor backgrounds.
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.
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.
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?
Doug Hellmann Growing so quickly is forcing us to think about how we organize our selves and make changes explicitly, and more rapidly, rather than allowing for a slower evolution. We've had a lot of blog posts and mailing list threads talking about ways to handle the growth through governance model changes to the project. These are important decisions for us to make as a community, and we need to weigh both sides of each issue carefully.
For example, we want to be more inclusive and bring more project teams into OpenStack, but doing that further strains our cross-project teams' capacity to help us all with documentation, infrastructure, and release management. More creative independence for projects can increase complexity for deployers and users as we drift away from consistent patterns. Providing incentives for creating new projects may take away incentives for collaborating on existing projects, ultimately hurting both projects. In each of these cases we want some aspects of both sides of the equation, but we need to strike a balance.
Working out the changes we need to our existing set of policies will take more thought and discussion , as we try to predict the consequences of the proposed changes and craft new policies that are flexible enough to continue to maintain a healthy community.
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.
Russell Bryant Just like any organization with growth, we have growing pains. I’d say identifying and working on these growing pains has always been a core part of what the TC does. I expect that to continue to be the case. The coming cycle appears to be no different.
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.
Dean Troyer As I wrote above, we have lost focus as we have attempted to widen the scope of integrated projects. Rather than do a smaller number of things very well the pressure is to do a lot of things.
Topic: New Contributor Experience: How would you characterize the experience new contributors have currently?
Dean Troyer The mechanics of contributing (CLA, accounts, etc) could be much better. I am not convinced that the CLA is providing value. The percentage of initial contributions that I see that are more than trivial spelling fixes or similar is low, as they need to focus on the process rather than the content just to get going.
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.
Doug Hellmann There's no question that OpenStack has a steep learning curve, both as a user and a contributor.
Documentation is useful as a reference, but there's nothing quite like having an experienced guide helping you first hand. I had the benefit of a couple of informal mentors when I started contributing. They walked me through the long process of setting up the tools and development environment I needed until I was able to submit my first patch, helped me get the most out of the design summit, and generally eased my entrance into the community. Today we have a few formal programs in the community to match mentors and new community members. Those programs deserve our support, but day to day, we can all do a little bit to help each other out by answering questions and sharing our knowledge freely.
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).
Russell Bryant I suspect being a new contributor would be quite overwhelming. Joining a project of this size and activity level is daunting for several reasons. I welcome and applaud all efforts to help onboard new contributors.
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?
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.
Doug Hellmann Our growth is making communication more challenging, but we are adapting.
The specs process has helped with technical planning, setting expectations, and recording decisions. Still, we have a lot of initiatives not tied directly to specs -- especially those that span project boundaries and releases.
I told the Oslo team that my mantra for this cycle is "Write it down," by which I mean we should clearly document our discussions and decisions so when a topic comes up again we do not have to rely on our memory. IRC is a great medium for quick iteration, but it's lousy as a historical record.
Communication is the key to maintaining a healthy open source community. Keeping up can be difficult, but we all have to pay attention to the messages coming out of other teams, to watch for anything relevant, then participate in the conversation.
Russell Bryant The way we communicate seems pretty typical for most open source communities. We have a heavy emphasis on mailing lists and IRC. We have a significant amount of in person meetups as well. For those that are able to make it, I think they help. We just need to continue to be sensitive to community members that can’t attend all events. Good documentation of discussions and allowing discussions to continue on the mailing list are important. This is largely done well already, but it’s important that we continue to emphasize it.
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.
Dean Troyer There are enough different communication channels available that it is hard for anyone to monitor them all and still have time to write. I do think in general we have done a good job of herding conversations toward the mailing lists and logged IRC channels. Twitter and personal blogs are other common avenues and may or may not be easy to discover if one doesn't already know about them.
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?
Dean Troyer I have mostly seen the interaction around the DefCore work and have found it interesting that neither side seems to want to say “This Is OpenStack” for fear of stepping on toes.
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.
Doug Hellmann I have a somewhat better impression of the relationship between the TC and Board than has been expressed by other candidates. We are different groups, with different perspectives, but we are all working in what we consider to be the best interests of the OpenStack project and that means working together. The face-to-face meeting in Atlanta allowed some of that attitude to show through in ways that it doesn't always in IRC or phone meetings. We have had spirited debates on topics like DefCore and the CLA, as is natural for groups with such different perspectives, but we are also continuing to work together to find ways to solve those and other issues.
Russell Bryant Our interaction has been improving. We’ve started holding joint meetings at the OpenStack summit. There has also been quite a bit of interaction on the DefCore topic specifically throughout the development cycle. I look forward to continuing to collaborate with the board on the topics where it makes sense.
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.