[openstack-dev] [heat] spec-lite for simple feature requests
ramishra at redhat.com
Wed Jan 20 15:21:51 UTC 2016
As discussed in the team meeting, below is the proposed spec-lite process for simple feature requests. This is already being used in Glance project. Feedback/comments/concerns are welcome, before we update the contributor docs with this:).
tl;dr - spec-lite is a simple feature request created as a bug with enough details and with a `spec-lite` tag. Once triaged with status 'Triaged' and importance changed to 'Whishlist', it's approved. Status 'Won’t fix' signifies the request is rejected and 'Invalid' means it would require a full spec.
Heat Spec Lite
Lite specs are small feature requests tracked as Launchpad bugs, with status 'Wishlist' and tagged with 'spec-lite' tag. These allow for submission and review of these feature requests before code is submitted.
These can be used for simple features that don’t warrant a detailed spec to be proposed, evaluated, and worked on. The team evaluates these requests as it evaluates specs. Once a bug has been approved as a Request for Enhancement (RFE), it’ll be targeted for a release.
The workflow for the life of a spec-lite in Launchpad is as follows:
1. File a bug with a small summary of what the request change is and tag it as spec-lite.
2. The bug is triaged and importance changed to Wishlist.
3. The bug is evaluated and marked as Triaged to announce approval or to Won’t fix to announce rejection or Invalid to request a full spec.
4. The bug is moved to In Progress once the code is up and ready to review.
5. The bug is moved to Fix Committed once the patch lands.
In summary the states are:
New: This is where spec-lite starts, as filed by the community.
Triaged: Drivers - Move to this state to mean, “you can start working on it”
Won’t Fix: Drivers - Move to this state to reject a lite-spec.
Invalid: Drivers - Move to this state to request a full spec for this request
Lite spec Submission Guidelines
When a bug is submitted, there are two fields that must be filled: ‘summary’ and ‘further information’. The ‘summary’ must be brief enough to fit in one line.
The ‘further information’ section must be a description of what you would like to see implemented in heat. The description should provide enough details for a knowledgeable developer to understand what is the existing problem and what’s the proposed solution.
Add spec-lite tag to the bug.
More information about the OpenStack-dev