confirmed On 08/10/14 05:51 AM, Eoghan Glynn wrote: > > > 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 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev