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

[sankarshan]

On Tue, Mar 25, 2014 at 9:44 PM, Andre Klapper <aklapper at wikimedia.org> wrote:
> Hi,
>
> as I (being in charge of Bugzilla) was asked:
> I am fine with moving away from Bugzilla once we have found something
> working "reasonable well" for "us". These two terms need defining,
> though.
>
> I'm sharing this to create awareness. Some stuff is general, but I
> mostly refer to Phabricator (which seems to be the favorite currently in
> https://www.mediawiki.org/wiki/Project_management_tools/Review/Options )
>
>
> 1) "us" (Personas)
>
> So far, focus was on discussing the needs of developers, maintainers and
> managers.
> But we also have users/reporters, triagers/bugwrangler, and the tech
> admin in a tracking/planning tool.

(I am not very familiar with the functional usage/importance of
Bugzilla in the development workflows of WMF projects)

An aspect of Bugzilla that is not called out is its ability to provide
inputs towards capacity planning ie. resources, features and releases.
So, while by its very name it is a defect tracking tool, the class of
content it contains (bug reports, reproducer detail,
patch-attachments, release tags etc) enables a form of accountability
to the various roles of Reporter/User, Triager, Developers, QA etc All
said, it is is implicitly an user-support tool (in terms of report
defect; receive fix; denote resolution) as well as being a
developer-onboarding tool (there have been instances where projects
have used keywords to identify easy-to-fix issues and coached
potential contributors)

A migration to a new tool would have the choice of either considering
making these personas and roles modular and cross-linked or, take them
across on a wholesale basis with similar functional experience.

> 1.3) General
>
> * How to do cross-component tagging ("keywords"): If nothing similar
> exists, use dependencies? Are keywords important to us?

Do you use keywords on the current instance of the Bugzilla? If so,
how do you utilize keywords? Do you also have a definition of what
each keywords signifies (eg. something similar to
<https://bugzilla.redhat.com/describekeywords.cgi>)?

> 3) Bugwrangler role/scope; Tech maintenance
>
> WMF's bugwrangler role would likely change to more bug report handling
> and less tracking/planning tool code maintenance.
> Somebody would have to work on the new tool's code to make it fit our
> needs, obviously.

A bugwrangler role does perform an important aspect of program
management. Do you see the change in tooling taking away the need to
focus on managing inputs to projects because the reported
bugs/features will already have priorities assigned?

Finally, thank you for sharing the note. I did make a hasty set of
snippets. But, your note provides a good set of perspectives for a
similar migration that I am peripherally involved in at my day-job.


-- 
sankarshan mukhopadhyay
<https://twitter.com/#!/sankarshan>