Open Stack

Searchlighters,

When we began this project, we had many discussions about process and made a conscious decision to support as lightweight of a workflow for feature requests as possible. We all discussed how we want to encourage contribution from everybody by supporting both developers and non-developers who want to provide input, requests for features, and bug fixes. Specifically, we decided that we did not want to immediately use a separate spec repo and to try to better incorporate our normal documentation repo into the feature request process whenever Launchpad didn’t meet our needs.

We did not formally document any of the above, mostly because we didn’t have time in Liberty, but also because the concept was still a little nebulous on how we would better incorporate our normal documentation processes into the feature request process.

Now that we are starting Mitaka, I’ve already encountered a couple of features where I felt that we needed a better review tool (e.g. gerrit) than launchpad. So, I’ve made an attempt [1] at documenting how we can still follow our original intents that I mention above. I also have a dependent feature review that follows this process as an example [2].

Please take a look at the workflow proposal review and provide comments. We also will discuss this in our weekly meeting. I recommend starting with this file: doc/source/feature-requests-bugs.rst

[1] Workflow Proposal - https://review.openstack.org/#/c/243881/
[2] Zero Downtime Feature - https://review.openstack.org/#/c/243386/


Steve,

Regarding you email [3] below.  I feel that the associated blueprint is an example of a blueprint that could benefit from a similar Gerrit review as described above. What do you think?

[3] Admin indexing - http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/68685

Thanks,
Travis