Thoughts on making OpenStack community more user friendly

It’s well know that OpenStack is really fast growing community. More and more contributors are working on various features in more and more projects. Such interest produce a lot of scale issues for every OpenStack project team. Which sometimes produce fast and not enough thought up decisions. Some of those rules are making upstream work quite hard and annoying.

There are few places in OpenStack that could be rethink:

1. Projects should have feature request mechanism

So there should be easy way to propose new ideas to project community. At this point we have only two:

  1. Bugs on Launchpad
  2. Project-Specs repo

Both are not nice. Launchpad bugs are not reviewed/approved by PTL and core team. Project-specs are too complicated to write (you need to specify too much information related to implementation and how it affects project and who will work on and so on just to get it approved).

In Rally we tried a bit different approach called Feature request. So You actually shouldn’t write long poems. You should put just short description of what you need without deep technical overview.  Feature request shoot 2 birds with one stone: They are structured, unified and well reviewed (like specs), but as well they are very easy to propose (like bugs on launchpad)

2. Specs shouldn’t be required for everything

Specs are really nice approach for distributed teams to discuss huge changes/features in projects. But I really don’t think that they are required for any changes in project. Developers dislike bureaucracy and adding such steps makes their life harder and unhappier.

3. Project team should work on abandoned patches

Sometimes developers that were working on some features switch to other tasks and stop working on some patches. As a result patches are marked as abandoned and hidden from everybody eyes. I think it’s a huge mistake because such patches usually covers somebodies use cases. Finishing such patches mean being more oriented on end users requests.

4. Avoid -2 (“do not merge”) mark

There are few reasons why you shouldn’t use this mark:

  1. It demotivates author that spend a lot of time working on patch
  2. It is not user friendly. Instead of “help” contributor understands that he is not welcome.
  3. It’s not enough “open”. Nobody reviews patches with -2 mark. It means that only 1 person decide does this patch belong to project code or not. People are not robots they make mistakes, which means that good changes can be blocked forever.


Instead of making new layers of bureaucracy and new rules “how to avoid helping contributors”. Let’s try to figure out how to make community more friendly and improve contribution process. Reducing amount of specs, adding feature request and working on abandoned patches may be a good first step.

One thought on “Thoughts on making OpenStack community more user friendly

  1. Boris, my +2 on #1, #3 and #4.
    I was thinking about short feature requests and no design spec for many small features. I think short feature request is excellent idea and definitely has to be used across all OpenStack projects, in order to show use case and approach to solve the problem in small paragraph of text.

    I do not agree though on skipping detailed specs for “small” features. The problem is that you never know whether the feature is small or not, and you can’t really define one. Even for very small feature, you can end up with scalability / doc / upgradability / client impact, which you didn’t think of. I believe that detailed spec gives following benefits:
    a) it starts from the template with questions, like the one we use in Fuel:, and you won’t forget about upgrades / etc.
    b) if no upgrade impact, how fast is it to put “no impact”? If feature is truly small, then spec will be small as well – and quickly created from the template.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>