Hello Stackers, I would like to announce my candidacy for Nova PTL in the Rocky cycle.
I have been a core reviewer on Nova since May 2015 and have been working with OpenStack since mid 2012 (ancient times!) and you may know me on IRC as melwitt. I have been both a user and a developer on OpenStack, so I think I see things from a bit more of an all-around perspective. I’ve worked in a company where we ran private OpenStack clouds, so I’ve done deployments, I’ve debugged production issues, I’ve worked on custom internal-only patches -- you name it. Having experienced all of these situations has given me a special interest in solving problems for users, operators, and developers. It has been my mission to work with all of you to help make Nova better. Like Matt, I see the Nova PTL role as a service position to the community. The PTL is there to help the team get things done in Nova. That means keeping track of the schedule, keeping tabs on ongoing work and helping people make progress if they’re stuck, facilitating cross-project communication when we’re working on things that integrate with other projects, and easing contribution to the project. On the last point, I have some ideas around easing contribution, mostly having to do with situations where someone may have researched a bug, found a root cause, and can propose a patch, but don’t have the time or knowhow to provide a patch complete with test coverage. In cases I have seen, I reached out to the person and asked if they would mind if I wrote tests for their patch and added myself as co-author. Not only did they not mind, they were happy I offered. So, as an experiment, I would like to keep a list of patches (in the Priorities etherpad) where authors add links to patches they’d like help with in exchange for co-authorship. If a more experienced contributor finds a patch in the list that they’re interested in, they can jump in and fill in the gaps so we end up with a complete patch ready-for-review. In this way, I would like to try to give less experienced authors the opportunity to pair with more experienced authors on patches. Speaking of the Priorities etherpad [1], I’d like to bring it back to active use. It’s a good way IMHO to track ready-for-review patches on the various sub-teams, virt drivers, and blueprints that we have. I think we have been good at reviewing high priority project patch sets but I think we could use more focus on reviewing lower priority blueprint work. I’d like to add a section for approved blueprints to increase visibility on those patches, so that ready-for-review patches don’t get lost in the shuffle. Regretfully, there have been a number of blueprint patches that were ready for review early on in the cycle and did not receive review for lack of visibility. I’d like to do something to keep track of those patches and get the ball rolling on review earlier in the cycle, before the higher priority work ramps up too much. I think keeping a section in the Priorities etherpad for these could help, along with a brief report/reminder of that section’s status in Nova meetings. Bug triage has fallen a bit behind in more recent cycles and I’ve been thinking about how we could improve that. In the past, we had a model where we tag bugs with an area (like ‘api’, ‘compute’, ‘volumes’) and tag owners [2] were responsible for triaging bugs with their tag. The idea is that bug tagging (categorizing) is a quick and simple task that doesn’t require much time. Then, the more time-consuming task of triaging the validity and severity of bugs is load-balanced among tag owners. I’d like to refresh the bug tag owner list and see if we can get back into a pattern where we can spread out bug triage among the team and make more progress there. Another area that could be improved is our communication of “low hanging fruit” work suitable for newer contributors. To be honest, I don’t find much in Nova to be “low hanging fruit” but do want to make an effort to collect and maintain a list of bugs and tasks that are better starting points for people who want to work on Nova. Long ago, we had the low-hanging-fruit etherpad [3] and I’d like to resurrect it to keep track of things that newer contributors could pick up. I think Matt has done great work to increase communication across projects we integrate with and with the operator community. I would like to continue that work to maintain those relationships and continue to keep the operator community apprised of changes in Nova that will affect them. I know we are not perfect here but we endeavor to keep the communication lines open and I, for one, welcome feedback on areas we fall short so that we can improve. We got a lot done in Queens, completing 36 out of 42 approved blueprints. I would like to keep that momentum going into the Rocky cycle. I have liked the model of using the PTG to discuss and prioritize work for the cycle and maintaining a detailed PTG etherpad to organize the agenda, document action items, next steps, and conclusions for each topic. I think this model is especially helpful for those who cannot attend the PTG in person, in that they can present their topic for discussion by adding it to the etherpad, we discuss it at the PTG, and then we can follow up asynchronously afterward on IRC or the dev mailing list. Finally, testing and the health of the gate is important to me and I would like to continue the work we’ve done here to actively monitor our test jobs, increase our test coverage, and troubleshoot and solve issues in the gate so that everyone can get their patches tested and merged smoothly. I know things have been challenging in this area lately, but we’ve all worked hard as a team to jump on each problem as it crops up and I’ve been proud of how much everyone has stepped up to help. I feel like I’ve written a lot here, thank you for reading and I appreciate your consideration. -melanie [1] https://etherpad.openstack.org/p/pike-nova-priorities-tracking [2] https://wiki.openstack.org/wiki/Nova/BugTriage#Tag_Owner_List [3] https://etherpad.openstack.org/p/nova-low-hanging-fruit __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
