[teampractices] Bugzilla migration Re: Project management tools review: Regressions/tradeoffs; migration

[Luis Villa]

On Fri, Mar 28, 2014 at 3:42 PM, Quim Gil <qgil at wikimedia.org> wrote:

>
>
> On Friday, March 28, 2014, Luis Villa <lvilla at wikimedia.org> wrote:
>
>>
>> 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.
>>
>
> 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.
>

Well, not WONTFIX (see below) but yes, and it got me flamed so (in)famously
that it created a software development meme [CADT - see
lu.is/?p=2679<http://t.co/84XlPnUOKa>].
It was the right call, because it allowed developers to more easily use the
tool and helped speed up development of the current codebase.

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".)


> 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.
>

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?"

[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.]


> 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.
>

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.

Luis


> 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:
>
> 0. Announce that Bugzilla will be closed in two years from
> {{CURRENTTIMESTAMP}}.
>
> 1. Close the creation and reopening of bugs in Bugzilla; keep the rest as
> it is now. All new/reopened reports go to Phabricator.
>
> 2. Let people work with the open bugs in BZ if this is what they want.
> Don't push anybody out.
>


> 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.
>
>
>
3b. All the better if a tool can be made available to maintainers willing
> to migrate bugs in batches or by components.
>
> 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.
>
> 5. At the end of the two years, close everything with that last message.
>
> PS: two years or whatever time is agreed, it's a secondary detail.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20140328/4dc8ad0c/attachment.html>