<div dir="ltr">Robert, <div><br></div><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"><span style="font-size:12.8000001907349px">So I think we should explicitly leave room for experimentation and<br></span><span style="font-size:12.8000001907349px">divergence, but also encourage a single common path - don't be<br></span><span style="font-size:12.8000001907349px">different to be different, be difference because it is important in<br></span><span style="font-size:12.8000001907349px">this specific case.</span></blockquote><div><br></div><div>First of all feature request are the same process as specs (in other projects)</div><div>Difference is what we are expecting to get in spec and feature request (and auditory) </div><div><br></div><div>By the way feature request in Rally were introduced<b> far far before backlogs in other Keystone and Nova.</b></div><div>It strange from me that those projects are reinventing working mechanism from other project=( and not just use it.<br></div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 14, 2015 at 11:45 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15 May 2015 at 08:34, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
><br>
> Hi Maish,<br>
><br>
> I would support this kind of thing for projects that wish to do it, but at<br>
> the same time, I wouldn't want the TC to mandate all projects use this<br>
> method of collecting feedback. Projects, IMHO, should be free to<br>
> self-organize as they wish, including developing processes that make the<br>
> most sense for the project team.<br>
<br>
</span>I think there is a balance to be struck. Where we tell users and<br>
operators to learn something different for every project, that has<br>
real impact. It makes it harder to engage with us, and it makes it<br>
harder to move between projects for contributors.<br>
<br>
Imagine if we had a spread of gerrit, github PR's, launchpad reviews,<br>
gitlab PRs and bitbucket PR's - say nova, swift, barbican, keystone<br>
and glance. That sounds silly because we all recognise the costs of<br>
switching there: I think we need to recognise the costs for other<br>
people even in things that as developers we don't interact with all<br>
that much.<br>
<br>
So I think we should explicitly leave room for experimentation and<br>
divergence, but also encourage a single common path - don't be<br>
different to be different, be difference because it is important in<br>
this specific case.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>