<div dir="ltr">Something that I have not pushed very hard but is something I prefer is to place features in relevant blueprints and keep bugs as bugs.<div><br><div><div>I haven't pushed the blueprint vs bug mainly because the team has been both responsive to correctly followup and responsible in understanding the difference. And people do track bugs very well whereas blueprints are less adopted in that sense of continuous followup.</div>
</div></div><div><br></div><div>What do you think of using blueprints for bugs-which-are-really-features ?</div><div><br></div><div>I don't mind leaving the bug open as "wishlist" & linking it.</div><div>
i will say, having a feature on a blueprint is a great way for it not to be overlooked/forgotten/lost with respect to roadmap planning.</div><div><br></div><div>br,kg</div><div><br></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Tue, Oct 15, 2013 at 2:10 AM, Daniel van Vugt <span dir="ltr"><<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We always seem to have lots of enhancements logged as bugs in the Mir project. And we seem to have a requirement that many of them be more important than "Wishlist" which is what LP historically uses to represent enhancements.<br>

<br>
So assuming we can't convince everyone that all enhancements should be Importance==Wishlist, how about some other formal approach?<br>
<br>
Maybe prefix all enhancements as "[enhancement]" ?<span class="HOEnZb"><font color="#888888"><br>
<br>
- Daniel<br>
<br>
-- <br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/<u></u>mailman/listinfo/mir-devel</a><br>
</font></span></blockquote></div><br></div>