open source marketer and community manager

Month: July 2014

If you try to solve a problem with the wrong tool you’re likely going to have a frustrating experience. OpenStack developers have been using the same workflow to plan and manage development of OpenStack software over time, they chose a set of tools appropriate for the project’s software development. Developers use blueprints define the roadmap for the various projects, the specifications attached to a blueprint are used to discuss the implementation details before code is submitted for review.

These are the tools for the developers and this doesn’t mean that blueprints and specifications are the only way to interact with developers. Operators and users in general don’t need to dive in the details of how OpenStack developers organize their work and definitely should never be asked to use tools designed for and by developers. When I read Dafna Ron (daffiduck)‘s post the place of a non-developer in the openstack community I immediately felt her pain: she was asked to use the wrong tool to solve a problem. I think this case is a major misunderstanding but the comments on the post signal that this is not an isolated case.

The most common way for a non-developer to highlight a flaw in OpenStack is to file a new bug report. Bugs can be defects that need to be fixed or they can be requests for enhancement. In this case, Dafna filed a bug report and interacting with the triager, they agreed that the reported bug was not a defect per se but more of a request for enhancement, a wishlist.

In order to fix a defect or implement a wishlist item, developers need to file a blueprint (and a specification) before they can start writing code. If the person who filed the original bug report is also a developer then s/he can go ahead and continue carrying on the process, file a blueprint to solve a bug # and write specifications (when needed) to describe the details of the implementation. Users interested in the bug can chime in adding comments to the bug and to the specs, provide input to developers.

The process above works in similar way when the person filing the bug is not a developer, like in Dafna’s case. The proper flow of bug #1323578 would have not required Dafna to file a blueprint and specs, but to have a developer do that. Users are required to interact closely with the developers to discuss the implementation details, and that’s where the new specifications process helps. Gerrit may not have the best UI but it’s definitely better than holding discussions on a mailing list. Adding comments and holding conversations with the developer assigned to resolve the issue, on the bug report itself is also a valid option.

While I think that as a community we have plenty of ways to improve how we include users and operators in our conversations, in this particular case, I think frustration came from being pulled in the wrong place from the beginning.

PS: To be super-clear, in this post I’m using the terms developer and operator to describe a role, not a person. One person can be at the same time a developer and an operator, and act at times as a developer writing blueprints, submitting code and as an operator filing bug, giving comments to specifications.

The OpenStack project doesn’t have a product manager but all companies shipping products based on components developed inside the OpenStack project have product managers. Currently the managers of OpenStack-related products don’t have a way to coordinate their efforts and they constantly have to struggle with OpenStack’s upstream developers, some of them working for the same company and some would not. Rob Hirschfeld, Allison Randal and Sean Roberts called them ‘hidden influencers’: product managers definitely contribute to shape OpenStack as much as users/operators and developers and yet they don’t have a forum to talk to each other and to the rest of the community.

Dave Neary and I started talking in Hong Kong about the opportunity to start a working group for product managers and now I think the time is ripe to create one. I just proposed to create a mailing list to coordinate the first activities and I ask you to chime in. If you think that the mailing list is a good way to start giving product managers a voice in the OpenStack community, please leave your comment on gerrit. I’ll be chasing product managers to sign up to the list in the coming weeks.