<div dir="ltr">+1 <div>Great idea. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">>many times you think that you know a way to do something but as you go<br></div><div class="gmail_extra">
>you then realize that doing it in another way is much better, so I</div><div class="gmail_extra">>think that in order to propose a new feature we should not assume that</div><div class="gmail_extra">>the author knows _everything_ at the start.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Absolutely agree. <br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">It would be great to have kind of design stages. </div><div class="gmail_extra">
0) Bare idea, feature scope, use cases.</div><div class="gmail_extra">1) Preliminary architecture and API. Here we can start writing and reviewing code.</div><div class="gmail_extra">2) Detailed understanding of architecture and API. Writing code, testing, detailed discussing, debugging.</div>
<div class="gmail_extra">3) Merging feature into master, debugging.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div>Vladimir Kozhukalov</div></div>
<br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 2:08 PM, Lucas Alvares Gomes <span dir="ltr"><<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
+1 for me as well, I'd like to have a better way to track incoming features.<br>
<br>
Also, as part of the migration progress I think that we need a good<br>
wiki page explaining the process of how propose a new feature, with a<br>
template of what's mandatory to fill out and what is optional. I<br>
wouldn't like to have something like nova currently have as its<br>
template[1], I don't know what is mandatory there and what's is not,<br>
many times you think that you know a way to do something but as you go<br>
you then realize that doing it in another way is much better, so I<br>
think that in order to propose a new feature we should not assume that<br>
the author knows _everything_ at the start.<br>
<br>
[1] <a href="https://github.com/openstack/nova-specs/blob/master/specs/template.rst" target="_blank">https://github.com/openstack/nova-specs/blob/master/specs/template.rst</a><br>
<div class=""><br>
On Fri, Apr 18, 2014 at 10:25 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
><br>
> Chris Behrens wrote:<br>
> > +1<br>
><br>
> FWIW we'll have a cross-project workshop at the design summit about<br>
> tracking incoming features -- covering blueprint proposal, approval and<br>
> prioritization. We'll discuss extending the "-specs" repositories<br>
> experience and see how it fits the whole picture on the long run:<br>
><br>
> <a href="http://summit.openstack.org/cfp/details/3" target="_blank">http://summit.openstack.org/cfp/details/3</a><br>
<br>
<br>
</div>But before we do it I think it might worth waiting to see the output<br>
of this session that<br>
Thierry pointed out.<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>