<div dir="ltr">On Fri, Mar 28, 2014 at 3:42 PM, Quim Gil <span dir="ltr"><<a href="mailto:qgil@wikimedia.org" target="_blank">qgil@wikimedia.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<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"><div><br><br>On Friday, March 28, 2014, Luis Villa <<a href="mailto:lvilla@wikimedia.org" target="_blank">lvilla@wikimedia.org</a>> 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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>Bugzilla/future bug tracking system, first and foremost,
has to serve the developers by helping them figure out what to work on
next. Old bugs can make the BTS less effective at that goal, by cluttering developer queries.</div></div></div></div></blockquote><div><br></div></div><div>Have you been in a free software community where old bugs were WONTFIXed en masse? Because Andre and me have, and at least for me it wasn't funny.</div>
<div></div></blockquote><div><br></div><div>Well, not WONTFIX (see below) but yes, and it got me flamed so (in)famously that it created a software development meme [CADT - see <span class=""><a href="http://t.co/84XlPnUOKa" rel="nofollow" dir="ltr" class="" target="_blank" title="http://lu.is/?p=2679">lu.is/?p=2679</a></span>]. It was the right call, because it allowed developers to more easily use the tool and helped speed up development of the current codebase.</div>
<div>
<br></div><div>To be clear, I don't know if it is the right approach for b.wm.o - I don't follow it closely. I'm just suggesting that mass NEEDINFOing should be considered as one option, and listing some factors that you might consider when doing it. (Seemed particularly relevant as a data point for the broader list's theme of "team practices" as opposed to "what is Wikimedia going to do right now".)<br>
</div><div> </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"><div>That was in Maemo, a community where WONTFIXing bugs nobody planned to fix was fine. Our current practice in Wikimedia is to leave those bugs open (with Lowest priority), WONTFIX only what goes against current or planned implementations. A test I don't recommend you to run: go to our Bugzilla, and WONTFIX five minor bug reports from 2008 that you can still reproduce today. Sit and wait.</div>
<div></div></blockquote><br></div><div class="gmail_quote">Agreed that WONTFIX is the wrong resolution; if you did it, the right resolution would be whatever b.wm.o uses to simulate NEEDINFO. Specifically, the information needed is "can you still reproduce this/is it still relevant in the newest release?" <br>
</div><div class="gmail_quote"><div><br></div><div>[WONTFIX is really pretty weird generally for open source projects, if you think about it. Either it is a bug of low priority, or a feature enhancement (WONTADD?), or it is as-designed/NOTABUG.]<br>
</div><div> </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"><div>But well, I don't want to just point "the community". I also think that nobody should WONTFIX reproducible bugs en masse, neither WONTFIX enhancement requests without actually reading them. Not because of the community flames that such moves will most probably create, just as a matter of principle.</div>
<div></div></blockquote><div><br></div><div>I think the most important principle for a BTS is "it must be useful for the developers". All other principles are subordinate. (Some important principles are implied from that first principle: it has to at least attract bug filers, else there is nothing else for developers to work on; and it must be useful for whoever sets priorities for developers, else the BTS does not help them get the right work done.) So clearing old bugs from default developer views (via triaging if that is possible, or in certain cases mass NEEDINFOs/closes) is a perfectly principled approach in certain conditions.<br>
<br></div><div>Luis<br>
</div><div> </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">
<div>This is the closest I believe we could reasonably get to the Selective approach (smaller migration, human driven), if we decide that for whatever reason the Automatic approach (bigger migration, tech driven) won't work:</div>
<div><br></div><div>0. Announce that Bugzilla will be closed in two years from <span style="font-family:monospace,Courier;font-size:14px;line-height:21px;background-color:rgb(249,249,249)">{{CURRENTTIMESTAMP}}</span>.</div>
<div><br></div><div>1. Close the creation and reopening of bugs in Bugzilla; keep the rest as it is now. All new/reopened reports go to Phabricator. </div><div><br></div><div>2. Let people work with the open bugs in BZ if this is what they want. Don't push anybody out.</div>
</blockquote><div> </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">
<div>3a. Provide a tool where someone introduces a BZ number, magic happens, the BZ report is RESOLVED MIGRATED, and the last comment contains a URL to a new PH task, that will link back to the BZ report.</div>
<div><br> </div></blockquote><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"><div>3b. All the better if a tool can be made available to maintainers willing to migrate bugs in batches or by components.</div>
<div><br></div><div>4. Organize bug triage sprints to go through the old inactive reports, either migrating them or resolving them with a message pointing to the migration tool, in case someone wants to reopen them.</div>
<div><br></div><div>5. At the end of the two years, close everything with that last message.</div><div><br></div><div>PS: two years or whatever time is agreed, it's a secondary detail.</div></blockquote><div><br> </div>
</div></div></div>