[openstack-dev] [nova] Austin summit "getting started in Nova" session recap
mriedem at linux.vnet.ibm.com
Wed May 4 00:15:20 UTC 2016
On Wednesday afternoon Sean Dague led a session on getting started in
Nova. The full etherpad is here .
In this session we discussed a lot of the bulk work items we have in
Nova right now, and how we can get newer people to the project involved
in helping on these as an introduction, and then 'ladder up' to more
We identified that we have a lot of low-hanging-fruit type bulk work
going on right now:
* Integrating support for python 3.
* Converting mox usage in tests to using mock.
* Cleaning up the api-ref documentation.
* Centralizing and improving the help for the config options.
* Cleaning up fake uuid usage in tests.
* Removing the NovaObjectDictCompat mixin from objects.
* Cleaning up random stacktraces from test runs.
* Addressing deprecation warnings from dependent libraries.
* Bug skimming/triage.
We also talked about how we can better advertise these with enough
details to on-board people that are looking to contribute.
We already have an etherpad for low-hanging-fruit  but etherpads get
messy once there is a ton of content in them. They also aren't indexed
by Google so they are hard to find. So we decided to move each major
item to a wiki page and add a template structure for each which would
* A contact person for each effort to provide more details for new
contributors interested in helping out with a particular item.
* An estimated difficulty level. For example, adding support for python
3 is pretty straight-forward, as is removing fake uuids from tests, but
removing NovaObjectDictCompat from objects is more complicated.
* Which part of the release cycle we'll focus on an effort, which is
generally the 1st and sometimes 2nd milestones. We don't usually do
these after the 2nd milestone in order to focus review effort on
features and bug fixes and to avoid regressions.
* A priority level. While most of these are low-priority, some are
higher priority than others so we can focus the work and get them done
so they don't drag on from release to release.
* Examples of existing changes to copy or to get an idea of the context
of the changes involved.
* Linking to the related blueprint for tracking the work and telling
people how to use the appropriate topic branch in Gerrit.
As far as advertising these, it's mostly going to be links from docs for
getting started in Nova. And if anyone is asking in the nova IRC channel
about things they can help with (it does happen), we can point them to
this. We might also have status updates in the dev list from the contact
people, but I'd leave that up to them and don't want to set hard rules
The idea of doing a recorded hangout session per effort was also brought
up so we could link that into the background context/education per item.
This would help with on-boarding so the contact person doesn't have to
repeat the same details every time someone new asks for help in getting
We might also create a Gerrit dashboard for these so people can easily
see what's ready for review. Sean has already started working on this
for the virt drivers  which we discussed in the Friday meetup session.
There is a list of volunteers at the bottom of the session etherpad.
Once we get the wikis created volunteers can start digging in, although
I already recognize some of the names as people working on at least one
of the items above.
Tony Breeds signed up to create the Gerrit dashboard.
We'll also need people to step up and own creating a wiki for each item
in the above list and transferring the information from  to the
respective wiki. There are contacts for some of the items in the
etherpad so I'll assume those same people will create the wikis. As for
the others, if there is already a blueprint I'll assume the assignee or
creator of the blueprint will create the wiki. For anything else, expect
your friendly neighborhood PTL to gently prod some people.
We didn't really get into the 'laddering up' part of the session. In my
mind this is something that will happen naturally with people that get
involved, stay involved and demonstrate their ability to work independently.
More information about the OpenStack-dev