I am announcing my candidacy for PTL for the Ironic team for the Queens release
cycle. In case you don't know me, I'm dtantsur on IRC. I started working on
Ironic around late spring or summer 2014 (oh, time flies!), and has been
dedicated full time to bare metal provisioning since then.

I am not going to surprise anyone, if I say that the Pike cycle was a difficult
one. We've gone through removing four cores and through several iterations of
re-prioritization. The team has done an amazing job keeping the pace - thank
you all for that. This also required me to change my personal priorities for
the cycle, concentrating more on keeping the project healthy and going. I hope
I did not let you down.

If you elect me, I would like to concentrate on the following efforts:

* CI and testing improvements.

  This was on my agenda for Pike, and I'm not giving up on it. We have
  introduced multi-node jobs, a standalone job. I believe that the 3rd party CI
  have become more reliable since the beginning of the cycle.

  I would like to broaden the use of the standalone tests in the main and in
  3rdparty CI to reduce the resource pressure and to be able to cover more
  important aspects of Ironic. I would like us to cover a few important testing
  gaps, such as testing adoption or root device hints.

* Improve the prioritization process.

  I believe that we have been doing really well with our weekly priorities
  process. However, we have clearly had too many big items on our plate this
  cycle. That required an extensive de-prioritization in the end, leaving
  people frustrated. That also made it harder for less-of-a-priority changes,
  such as vendor-specific patches to get in.

* Bug triaging.

  One of my PTL promises during the last election was to improve the bug
  handling process, and I apologize for not having done it. I would like
  to change it, and make sure that our bug backlog reduces instead of slowly
  growing. This may include better processes around incoming bug triaging,
  smarter dashboard and some automation, e.g. for handling old bugs.

* Stabilization and paper cut bug fixing.

  This is related to the prioritization topic above. We've been chasing big
  stuff over a few cycles. That was absolutely justified, and we've landed
  several absolutely mind-blowing features, such as ironic-neutron integration
  or boot-from-volume.

  Now, I think, it's time to slow down a tiny bit, and think of the things that
  can make every day life managing an ironic deployment easier. Treating of the
  maintenance mode, reporting of cleaning progress, error messages and logging,
  just to name a few.

  Of course, this includes documentation for operators. As you know, I've spent
  some substantial time this cycle writing and refining installation and
  operation docs. With the documentation reform in place we have even more
  power over them - let's use it wisely.

And as the last time, my significant goal will be not to get in a way of our
wonderful team :)

-- Dmitry Tantsur