I would like to propose my candidacy for the Neutron PTL. I have been the Neutron PTL for the Mitaka release, and I would like to continue the journey on which I have embarked upon a little over six months ago. Back then, I had a number of objectives which I wanted to achieve with the help of the Neutron team, and with this candidancy statement I would like to take the opportunity to look back and see what we have accomplished and what else is waiting ahead of us: * Stability is the priority: I have introduced a rotation mechanism for triaging and staying on top of bugs; with that, we have a very little percentage of bugs that go unacknowledged, and even though we only managed to fix only 60% of all bugs reported in the Mitaka timeframe, some might regard this as a remarkable achievement. I also made sure the Neutron projects was amongst the most stable one, by aggressively addressing intermittent failures, and by ensuring that failures did not impact the integrated gate. As of today, the success rate for Neutron (alone) is at >98%. We also worked hard to extend test coverage to DVR, Linuxbridge and Grenade multinode. Going forward, I'd like to focus on improving the stability of multinode jobs, and look at how we can do more reliable and exhaustive performance testing on a more regular basis. * Narrow the focus: we all know by now my attempt to address the needs and the issues of the Stadium, and the team effort aimed at standing up neutron-lib to allow for Neutron projects to loosely couple together. The journey is far from being over and I will continue to work towards a resolution that strikes a good compromise for everybody. On the other end, I worked hard with the rest of the drivers team members to ensure a coherent strategy and vision when assessing and approving RFE's. I proposed process changes to ensure that reviewers and contributors can be more focussed and work together towards a well defined goal. * Consistency is paramount: promoting the documentation of our practices (like our deputy, blueprint/rfe guidelines and release postmortem), as well as starting the 'Effective Neutron' guide have been two key areas that allowed our developers to have a common understanding on how we operate, review, develop and manage our project. More needs to be done to ensure we become 'more predictable' in terms of the software we produce and the quality associated with it, including end-user facing documentation. * Define long term strategy: when I started looking at this area, Neutron had 400+ blueprints targeted. I tried to put some sanity back into the feature submission process by limiting who can actually submit feature proposals (the drivers team) and by cleaning up the huge backlog of blueprints we had (currently we have 15 blueprints and 19 RFEs). That said this is an area where I feel I have not made enough of a dent to be satisfied. This is somewhat tangential to the needs of the Stadium, but I think we need more time to execute a plan of action that can yield positive results. * Keep developers and reviewers _aware_: I worked relentlessly to remind our reviewers to stay focussed and review what matters for a given release. I think we have achieved this with mixed success, and I know that some of us worked hard to give us the tools to help us stay more aware. * I would like to promote a 'you merge it, you own it' type of mentality: this is typically done by leading by example, and I am pleased to see that many of us take great pride in the code they review and merge. We need to continue to promote this attitude. And last but not least: * Improve the relationships with other projects: Nova and QA primarily. I personally feel that we went a long way to improve these relationships, from the technical front (for example by improving the provisioning workflow of networking resources for Nova instances - aka get-me-a-network, and by tackling the testing issues affecting Neutron) to the the social front, by having a good representation of contributors across multiple projects at the various mid-cycle events. There is always room for improvement, of course! If you liked what I did/said, then allow me to continue. Thanks for reading and, as usual, forgive the typos! Armando Migliaccio (aka armax)