On Wednesday afternoon Sean Dague led a session on getting started in Nova. The full etherpad is here [1].

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

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 [2] 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 include:

* 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 about this.

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

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 [3] 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 [2] 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.

[1] https://etherpad.openstack.org/p/newton-nova-getting-started
[2] https://etherpad.openstack.org/p/nova-low-hanging-fruit
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093753.html
[4] http://lists.openstack.org/pipermail/openstack-dev/2016-April/093538.html

--

Thanks,

Matt Riedemann


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to