On Thu, 2016-09-15 at 10:20 +0100, Steven Hardy wrote: > Hi all, > > As we work to finish the last remaining tasks for Newton, it's a good > time > to look back over the cycle, and recognize the excellent work done by > several new contributors. > > We've seen a different contributor pattern develop recently, where > many > folks are subsystem experts and mostly focus on a particular project > or > area of functionality. I think this is a good thing, and it's > hopefully > going to allow our community to scale more effectively over time (and > it > fits pretty nicely with our new composable/modular architecture). > > We do still need folks who can review with the entire TripleO > architecture > in mind, but I'm very confident folks will start out as subsystem > experts > and over time broaden their area of experience to encompass more of > the TripleO projects (we're already starting to see this IMO). > > We've had some discussion in the past[1] about strictly defining > subteams, > vs just adding folks to tripleo-core and expecting good judgement to > be > used (e.g only approve/+2 stuff you're familiar with - and note that > it's > totally fine for a core reviewer to continue to +1 things if the > patch > looks OK but is outside their area of experience). > > So, I'm in favor of continuing that pattern and just welcoming some > of our > subsystem expert friends to tripleo-core, let me know if folks feel > strongly otherwise :) > > The nominations, are based partly on the stats[2] and partly on my > own > experience looking at reviews, patches and IRC discussion with these > folks > - I've included details of the subsystems I expect these folks to > focus > their +2A power on (at least initially): > > 1. Brent Eagles > > Brent has been doing some excellent work mostly related to Neutron > this > cycle - his reviews have been increasingly detailed, and show a solid > understanding of our composable services architecture. He's also > provided > a lot of valuable feedback on specs such as dpdk and sr-iov. I > propose > Brent continues this exellent Neutron focussed work, while also > expanding > his review focus such as the good feedback he's been providing on new > Mistral actions in tripleo-common for custom-roles. > > 2. Pradeep Kilambi > > Pradeep has done a large amount of pretty complex work around > Ceilomenter > and Aodh over the last two cycles - he's dealt with some pretty tough > challenges around upgrades and has consistently provided good review > feedback and solid analysis via discussion on IRC. I propose Prad > continues this excellent Ceilomenter/Aodh focussed work, while also > expanding review focus aiming to cover more of t-h-t and other repos > over > time. > > 3. Carlos Camacho > > Carlos has been mostly focussed on composability, and has done a > great job > of working through the initial architecture implementation, including > writing some very detailed initial docs[3] to help folks make the > transition > to the new architecture. I'd suggest that Carlos looks to maintain > this > focus on composable services, while also building depth of reviews in > other > repos. > > 4. Ryan Brady > > Ryan has been one of the main contributors implementing the new > Mistral > based API in tripleo-common. His reviews, patches and IRC discussion > have > consistently demonstrated that he's an expert on the mistral > actions/workflows and I think it makes sense for him to help with > review > velocity in this area, and also look to help with those subsystems > interacting with the API such as tripleoclient. > > 5. Dan Sneddon > > For many cycles, Dan has been driving direction around our network > architecture, and he's been consistently doing a relatively small > number of > very high-quality and insightful reviews on both os-net-config and > the > network templates for tripleo-heat-templates. I'd suggest Dan > continues > this focus, and he's indicated he may have more bandwidth to help > with > reviews around networking in future. > > Please can I get feedback from exisitng core reviewers - you're free > to +1 > these nominations (or abstain), but any -1 will veto the > process. I'll > wait one week, and if we have consensus add the above folks to > tripleo-core. > > Finally, there are quite a few folks doing great work that are not on > this > list, but seem to be well on track towards core status. Some of > those > folks I've already reached out to, but if you're not nominated now, > please > don't be disheartened, and feel free to chat to me on IRC about > it. Also > note the following: > > - We need folks to regularly show up, establishing a long-term > pattern of > doing useful reviews, but core status isn't about raw number of > reviews, > it's about consistent downvotes and detailed, well considered and > insightful feedback that helps increase quality and catch issues > early. > > - Try to spend some time reviewing stuff outside your normal area of > expertise, to build understanding of the broader TripleO system - > as > discussed above subsystem experts are a good thing, but we also > need > to see some appreciation of the broader Tripleo archticture & > interfaces (all the folks above have demonstrated solid knowledge > of one > or more of our primary interfaces, e.g the Heat or the Mistral > layer) > > Thanks to everyone for the hard work during Newton, I'm looking > forward to > seeing what we can achieve during Ocata!
+1 to all of these nominations. Dan > > Steve > > [1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/0969 > 68.html > [2] http://stackalytics.com/report/contribution/tripleo-group/90 > [3] http://docs.openstack.org/developer/tripleo-docs/developer/tht_wa > lkthrough/tht_walkthrough.html > > _____________________________________________________________________ > _____ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
