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

Reply via email to