<div dir="ltr"><div dir="ltr">On Fri, Mar 29, 2019 at 5:37 AM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I definitely agree that we need a higher bar for moving something to<br>
approved than just "we thought this was a good idea in the past." I feel<br>
the same way about re-approving specs cycle-to-cycle, for what it's<br>
worth.<br>
<br>
Using the backlog directory is fine, but I don't really see any point in<br>
doing that versus just leaving things as unmerged in Gerrit. I'm sure it<br>
matters to someone, but merging something that meets the "sure, we can<br>
put that in the backlog" bar at one point in time, which still needs to<br>
be re-reviewed in order to put it in the "okay we will actually let this<br>
in now" realm seems like not that useful of a dance to me.<br></blockquote><div><br></div><div>I agree with Dan here. From a contributor's perspective what does having a spec in the backlog directory give me? The promise of a future conversation about approval? I have that in the form of a new review already.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Assuming it solves some not-obvious-to-me problem, as long as we retain<br>
the re-review requirement then I guess I have no objection.<br></blockquote><div><br></div><div>I think the problem the backlog directory solves is that it gives core a way to give a soft no that makes contributors less upset. I don't see a lot of value in that though. If the spec is a no then just say no. If its a big enough problem for the proposer they can hold their own patches or fork nova, much as people such as StarlingX, HP, and Rackspace Public Cloud did back in the day.</div><div><br></div><div>Michael </div></div></div>