+2 =)
On Fri, Mar 28, 2014 at 11:21 PM, Michael Still <mi...@stillhq.com> wrote: > Hi. > > I would like to run for the OpenStack Compute PTL position as well. > > I have been an active nova developer since late 2011, and have been a > core reviewer for quite a while. I am currently serving on the > Technical Committee, where I have recently been spending my time > liaising with the board about how to define what software should be > able to use the OpenStack trade mark. I've also served on the > vulnerability management team, and as nova bug czar in the past. > > I have extensive experience running Open Source community groups, > having served on the TC, been the Director for linux.conf.au 2013, as > well as serving on the boards of various community groups over the > years. > > In Icehouse I hired a team of nine software engineers who are all > working 100% on OpenStack at Rackspace Australia, developed and > deployed the turbo hipster third party CI system along with Joshua > Hesketh, as well as writing nova code. I recognise that if I am > successful I will need to rearrange my work responsibilities, and my > management is supportive of that. > > The future > -------------- > > To be honest, I've thought for a while that the PTL role in OpenStack > is poorly named. Specifically, its the T that bothers me. Sure, we > need strong technical direction for our programs, but putting it in > the title raises technical direction above the other aspects of the > job. Compute at the moment is in an interesting position -- we're > actually pretty good on technical direction and we're doing > interesting things. What we're not doing well on is the social aspects > of the PTL role. > > When I first started hacking on nova I came from an operations > background where I hadn't written open source code in quite a while. I > feel like I'm reasonably smart, but nova was certainly the largest > python project I'd ever seen. I submitted my first patch, and it was > rejected -- as it should have been. However, Vishy then took the time > to sit down with me and chat about what needed to change, and how to > improve the patch. That's really why I'm still involved with > OpenStack, Vishy took an interest and was always happy to chat. I'm > told by others that they have had similar experiences. > > I think that's what compute is lacking at the moment. For the last few > cycles we're focused on the technical, and now the social aspects are > our biggest problem. I think this is a pendulum, and perhaps in a > release or two we'll swing back to needing to re-emphasise on > technical aspects, but for now we're doing poorly on social things. > Some examples: > > - we're not keeping up with code reviews because we're reviewing the > wrong things. We have a high volume of patches which are unlikely to > ever land, but we just reject them. So far in the Icehouse cycle we've > seen 2,334 patchsets proposed, of which we approved 1,233. Along the > way, we needed to review 11,747 revisions. We don't spend enough time > working with the proposers to improve the quality of their code so > that it will land. Specifically, whilst review comments in gerrit are > helpful, we need to identify up and coming contributors and help them > build a relationship with a mentor outside gerrit. We can reduce the > number of reviews we need to do by improving the quality of initial > proposals. > > - we're not keeping up with bug triage, or worse actually closing > bugs. I think part of this is that people want to land their features, > but part of it is also that closing bugs is super frustrating at the > moment. It can take hours (or days) to replicate and then diagnose a > bug. You propose a fix, and then it takes weeks to get reviewed. I'd > like to see us tweak the code review process to prioritise bug fixes > over new features for the Juno cycle. We should still land features, > but we should obsessively track review latency for bug fixes. Compute > fails if we're not producing reliable production grade code. > > - I'd like to see us focus more on consensus building. We're a team > after all, and when we argue about solely the technical aspects of a > problem we ignore the fact that we're teaching the people involved a > behaviour that will continue on. Ultimately if we're not a welcoming > project that people want to code on, we'll run out of developers. I > personally want to be working on compute in five years, and I want the > compute of the future to be a vibrant, friendly, supportive place. We > get there by modelling the behaviour we want to see in the future. > > So, some specific actions I think we should take: > > - when we reject a review from a relatively new contributor, we should > try and pair them up with a more experienced developer to get some > coaching. That experienced dev should take point on code reviews for > the new person so that they receive low-latency feedback as they > learn. Once the experienced dev is ok with a review, nova-core can > pile on to actually get the code approved. This will reduce the > workload for nova-core (we're only reviewing things which are of a > known good standard), while improving the experience for new > contributors. > > - we should obsessively track review performance for bug fixes, and > prioritise them where possible. Let's not ignore features, but let's > agree that each core should spend at least 50% of their review time > reviewing bug fixes. > > - we should work on consensus building, and tracking the progress of > large blueprints. We should not wait until the end of the cycle to > re-assess the v3 API and discover we have concerns. We should be > talking about progress in the weekly meetings and making sure we're > all on the same page. Let's reduce the level of surprise. This also > flows into being clearer about the types of patches we don't want to > see proposed -- for example, if we think that patches that only change > whitespace are a bad idea, then let's document that somewhere so > people know before they put a lot of effort in. > > Thanks for taking the time to read this email! > > Michael > > -- > Rackspace Australia > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
