I led two sessions about community and participated in another few. All have actionable items. Below are the notes I took. In the next weeks I’d like to gather comments and proceed with implementation.
I showed the results of the work I’ve been doing with the metrics about OpenStack development. The plan is to build a datawarehouse that hosts data from git and the bug tracker, plus data from forums, mailing lists, IRC and gerrit. Currently the datawarehouse hosts data extracted from git. A couple of days before the summit the developers of bicho released the extension to gather data from Launchpad bug tracker (the job was sponsored by Rackspace). Mark McLoughlin used git-dm to gather data from OpenStack git repository, creating a good master data record for the association developer-company.
Many people liked the analysis done after the Essex release, while the weekly reports are less interesting. The other important comment is that we should all be careful with which numbers we decide to track as these can lead to “games” to trick the system.
I gathered that it would be more interesting to have monthly reports and more comprehensive coverage of what is going on with the project. Thankfully, Jake Dahn is working on a self service portal as a frontend to the datawarehouse (his work is on github).
General agreement is that the developers mailing list on Launchpad has too much traffic (see the chart http://openstack.markmail.org/). The plan is to keep the Launchpad list for general discussions and move developers to a new set of lists, managed by a powerful list manager that allows automatic tagging of messages, per project. Ideally, a developer would send a message about Quantum to something like openstack-dev-quantum@listmanager with subject “foo bar”. The message would have its subject changed to “[Quantum] foo bar” and it would be delivered to openstack-dev@listmanager. Even if mailman and other list managers have this feature, implementing and running a large email server like this would require resources. The openstack-infra team would help manage the machines but the actual email server administration should be done by somebody else. We need volunteers.
The IRC channels seem to be suffering: #openstack and #openstack-dev are not helping create a sense of cohesion among developers and users. The suggestion is to keep #openstack and split #openstack-dev into smaller channels for each project. The idea is that users and developers will all hang around #openstack, finding questions to answers while the smaller project-dedicated channels will help create bonds among developers.
How to help users get answers to their questions is the main issue we discussed in the section. Currently questions come in from messages to the mailing lists operators and developers, on forums, IRC channel, Linkedin group, Disqus on docs.openstack.org and more. The general feeling is that Launchpad Answers product is not adequate for the task, mainly because it’s hard to measure anything on it and since there are now six projects where you can ask question, and sometimes the answer is related to two projects not just one. The OpenStack forums seem to be gaining traction and should be advertised more prominently from openstack.org domain. We should investigate the possibility to use something similar to StackOverflow.
The OpenStack Planet suffers for having little visibility but, like the forums, it has lots of good content. Also, lots of content that could be in the planet, stays out because to add a blog you need to be a developer (to add your blog to the planet you need to use git and gerrit). There was consensus on adding a plugin to the OpenStack blog to manage syndication of content directly from openstack.org/blog and get rid of planet.
I moderated the panel with Boris Renski, Masanori Itoh, Joseph B George, Tristan Goode, Yoyo Chiang and important contribution from Heng Chui and Sammy Luo from China. There will soon be a video online but the gist of the session is that we need to add more content in local languages to openstack.org, and we need to publish and keep updating the document OpenStack User Group HOWTO. Other comments were that starting a new user group is easy, doesn’t need bureaucracy and it can help companies build a local reputation as OpenStack experts.
I used a few slides to introduce the topic Growing the OpenStack International Community: