<div dir="ltr">+1 from my side. I agree with this idea.<div><br></div><div>There is only one question from my side, which IMO we should describe in documentation:</div><div><br></div><div>Do we need to upload release-notes for such small features?</div><div>My guess is - Yes. I'd like to know what other guys think about it.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 January 2016 at 18:21, Rabi Mishra <span dir="ltr"><<a href="mailto:ramishra@redhat.com" target="_blank">ramishra@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
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:).<br>
<br>
<br>
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.<br>
<br>
<br>
Heat Spec Lite<br>
--------------<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
The workflow for the life of a spec-lite in Launchpad is as follows:<br>
<br>
1. File a bug with a small summary of what the request change is and tag it as spec-lite.<br>
2. The bug is triaged and importance changed to Wishlist.<br>
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.<br>
4. The bug is moved to In Progress once the code is up and ready to review.<br>
5. The bug is moved to Fix Committed once the patch lands.<br>
<br>
In summary the states are:<br>
<br>
New: This is where spec-lite starts, as filed by the community.<br>
Triaged: Drivers - Move to this state to mean, “you can start working on it”<br>
Won’t Fix: Drivers - Move to this state to reject a lite-spec.<br>
Invalid: Drivers - Move to this state to request a full spec for this request<br>
<br>
Lite spec Submission Guidelines<br>
-------------------------------<br>
<br>
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.<br>
<br>
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.<br>
<br>
Add spec-lite tag to the bug.<br>
<br>
<br>
Thanks,<br>
Rabi<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Regards,<div>Sergey.</div></div></div>
</div>