Open Stack

On Thu, Sep 15, 2016 at 5:20 AM, Steven Hardy <shardy at redhat.com> 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).

While I think this is good because our team is respectful about this
rule, I'm still thinking that's something we might want to revisit one
day.
In Puppet OpenStack, we created subgroups for specific modules because
some people were contributing to one modules and had one area of
expertise (ie: keystone for puppet-keystone), etc.

I guess we're fine now but having subgroups could help us to scale our
team by more proposing people working on a specific project more
quickly. Also, as long as we keep creating projects, it's not clear to
me who can really +2 a patch in this project.
Having subgroups would just clarify it. Anyway, this is not a critical
topic today but I might propose a change in the next months.

> 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.

Big +1. And not because he's Canadian :-)
Seriously, Brent, you're doing a great job and I'm looking forward to
seeing your next contributions to make networking better in TripleO.

> 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.

Same comment as Brent, Prad is always here to fix or improve Telemetry
things in TripleO. Keep going please :-)

> 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.

Carlos was very helpful for composability work during the cycle, +1!

> 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.

Yes! Ryan has dramatically contributed to this topic, he deserves core
review on tripleo-common and 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.

Although Dan is doing incredible work for networking too, I also would
like to see a bit more reviews (only 26 over the last 3 months).
Dan, please keep going in reviewing more code during the next months.
It really helps to increase the team knowledge in how we can make
networking better and it will probably make you more visible in the
project.

> 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!
>

Thank you Steve for your recognition against our contributors, that's
how a great community works!

-- 
Emilien Macchi