Folks,
I would like to throw my hat into the ring for the upcoming Technical Committee election. I've been involved in the OpenStack community for nearly three years, starting off by becoming core on glance, before moving my focus mainly onto the ceilometer project. Along the way I've landed a smattering of commits across nova, heat, cinder, horizon, neutron, oslo, devstack, and openstack-manuals, while contributing to the stable-maint effort over multiple cycles. More recently, I've served the ceilometer project as PTL over the Juno cycle, and will be doing so again for Kilo. I'm employed by Red Hat to work primarily upstream, but I also have some perspective on the "sausage machine" that operates downstream in order to put the technology we produce into the hands of users. My motivation in running is to bring more perspective from a smaller project to the deliberations of the TC, which I think already has a tonne of large-project and cross-project perspective to draw on. Balance is a good and healthy thing :) As a community we have a big challenge ahead of us to figure out how we respond to the growing pains that been felt in our governance structure and cross-project resources. This has crystallized around the recent layering and big tent discussions. My own feeling has always been in favor of a big welcoming tent, but I'm less convinced that a small blessed core is necessarily a corollary of such inclusiveness. Before we radically alter the release cycle model that's served us relatively well thus far, I think a critical eye should be brought to the proposals; in particular we really need to clearly identify the core problems that these proposed changes are intended to solve. And so, onwards to the stock questions ... Topic: OpenStack Mission ======================== How do you feel the technical community is doing in meeting the OpenStack Mission? 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. Topic: Technical Committee Mission ================================== How do you feel the technical committee is doing in meeting the technical committee mission? 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. Topic: Contributor Motivation ============================= How would you characterize the various facets of contributor motivation? 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. 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? It's clear that we're nearing an inflection point in our growth path, where the ability of our cross-project concerns to continue scaling up to meet the growing demand can no longer be taken for granted. My instinct on this is to first examine how we organize those cross-project concerns to see if the scalability ceilings can be raised, before going down the route of rationing these cross-project resources across a smaller set of projects. Topic: New Contributor Experience ================================= How would you characterize the experience new contributors have currently? To answer this question, I tried to project myself back to my own journey up the on-ramp. It was of course a simpler time in terms of the proliferation of projects and services, but the key elements have mostly remained the same. Firstly, the good ... One thing I found awesomely useful at the time was the ability to easily spin up an entire mini-cloud in a VM and just get my hands dirty, attempt to decipher the logs, snoop the messages passing between services, peek inside the databases and so on. Given that we rely on it so heavily in our day-to-day, it's easy to forget how helpful devstack really is. I found it a massive leg-up, coming from a scenario where setting up any kind of simulacrum of production was quite a gnarly task. I also found refreshing the willingness of various "old-timers" to answer my dumb noob questions in a friendly and non-judgemental way. We should never under-value this quality in our community, anyone who in a past life has struggled with knowledge-hoarding will attest to how open we are in this respect. Next, the bad ... We have a particular culture on gerrit were newbies sometimes feel they're being ignored, or at least that their patches are not getting the timely traction they expect. I know I fell into this trap myself back in the day, where I followed up a git push with an almost immediate full-court-press on potential reviewers via IRC. With predictably counter-productive results. I think we could better serve new contributors by setting more realistic expectations of review turnaround from the very outset. And finally, the ugly ... ;) Ah yes, the old Contributor License Agreement that many of us love to hate. TBH being required to sign this was more of an irritation to me when I first encountered it, but thanks to efforts over the last couple of cycles by some individuals on the TC, I now have a much clearer perspective on the real and practical difficulties this seemingly unnecessary legalism introduces for some contributors. Needless to relate, I'd be fully supportive of the TC's continuing efforts to replace the CLA with the Developer Certificate of Origin. Topic: Communication ==================== How would you describe our current state of communication in the OpenStack community? We have many "official" vectors of communication: the design summit, mailing lists, mid-cycle meetups, gerrit, logged IRC meetings and so on. All of these have their strenghts and weaknesses, but as a community we're learning to use and filter them quite well, despite their firehose-like nature. There is also an emerging trend for important discussions to be initiated and developed outside of these official channels, e.g. via ad-hoc discussions and blog posts. This is something I'm not so enthused about, as it's harder for such channels to host a two-way inclusive conversation. Also, as in any technical community that I've ever experienced, there's a lot of shared "tribal knowledge" sitting in peoples' heads. I'm as guilty of it as anyone else, perhaps even more so. That's just what happens day-to-day as the rate of knowledge accretion surpasses the time available to codify it. However we all need to try forcing ourselves to take the time to write such nuggets down in a discoverable place, in order to provide a bread-crumb trail for those who come behind us. Topic: Relationship with the Foundation Board ============================================= The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions? Interestingly, the membership of these two governance structures is somewhat intertwined. Obviously this presents challenges for the individuals involved in both, in ensuring that they can "swap hats" and context-switch appropriately. But it does at least ensure that the board is not resting in an ivory tower, insulated from the day-to-day technical leadership. In terms of the practical interactions that I've seen, I was heartened by the robust approach of the TC in making their preference to switch to the DCO crystal-clear and putting it up to the board to deal with the CLA issue once and for all. Cheers, Eoghan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev