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

[Quim Gil]

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.

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.

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.

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.


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20140328/18fc49dd/attachment.html>