<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 28, 2014 at 7:05 PM, Luis Villa <span dir="ltr"><<a href="mailto:lvilla@wikimedia.org" target="_blank">lvilla@wikimedia.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the most important principle for a BTS is "it must be useful for the developers". All other principles are subordinate.</blockquote>


</div><br>I really deeply agree with this. </div><div class="gmail_extra"><br></div><div class="gmail_extra">A bug tracker is really just a fancy to-do list for software development. The thing about to-do lists is that things which sit un-done on them for years and years just fade in to the background, and the prevent a feeling of momentum and "getting shit done". If we have thousands of stale unfixed bugs, it's not a good thing to treat this like a precious tome of knowledge that has to be preserved forever exactly how it is. <br>

<br>That said, I wasn't really calling for an automated clearing away of stale bugs. Rather, I think with elbow grease and a little optimism about the power of our community, we can import the bugs that really are priorities in to Phabricator. This teaches how to use the tool in a trial by fire, gets our staff/community to own the bug backlog for each component in a deeper way that doesn't lean on a few dedicated individuals who live inside Bugzilla 24/7, and it gets us a clean break with a nasty old tool that's not very well-supported by us or upstream. </div>


<div class="gmail_extra"><div><br></div>-- <br><div dir="ltr"><div><div><div>Steven Walling,</div><div>Product Manager</div><div><a href="https://wikimediafoundation.org/" target="_blank">https://wikimediafoundation.org/</a></div>


</div></div></div>
</div></div>