Hi everyone,
Now that the pending changes work is well underway, I'm reviving this
thread. Below are replies to Neil, Roan, and Chad:
On Mon, Jun 14, 2010 at 7:23 AM, Neil Kandalgaonkar <neilk(a)wikimedia.org>wrote;wrote:
Just starting off the discussion, but am I right in
assuming that this
is driven by a desire for time tracking / project tracking, and this
comes primarily from PMs at the WMF?
Yup. It started before I arrived at WMF, but part of my job is to evaluate
our tools and practice.
I sympathize but I'm skeptical about exactly how
much a tool alone can
improve things.
No one suggested it would.
In my experience, developer practice and communication
is what makes
projects stay on time.
No one is suggesting that a good tool is a silver bullet. What you seem to
be suggesting here though is that developer practice and communication *is*
a silver bullet, and that tools or (for that matter) anything else is just
fiddling at the edges.
Good project managers help developers improve communication and help
developers focus on development. A great project manager can work with any
tool, just like a great developer can work with any programming language.
However, people who are great at their job still prefer great tools.
If it seemed like Bugzilla power usage was a really deeply embedded into the
developer culture here, I wouldn't suggest exploring this. However, it
doesn't appear that MediaWiki devs are really Bugzilla power users at all.
Choice of issue tracker is nearly irrelevant.
Spoken like a true developer ;-)
A great project manager will suck it up and use whatever tool they're given,
but that doesn't mean that the tool is irrelevant. It is exceedingly
difficult to attract and retain great project managers to an environment
where they're told that the tools they use are nearly irrelevant.
Moreover, with the right tools, it might be more practical for community
members to help with the practice of project management. Certainly, there
are many people in the community anxiously awaiting many of the projects
that are currently in the pipeline. This community has (practically by
definition) an abundance of people that are good at organizing information.
That said, I can totally understand the desire for better measurement,
or tools like Gannt charts.
Fine grained measurement is less important than broad visibility into
milestones (e.g. bugs 1, 2, 3 are targeted at milestone A, and bugs 4, 5,
and 6 are targeted at milestone B).
The goal is to get some degree of predictability, and to give everyone
(inside and out) a sense of what Wikimedia Foundation developers are working
on, and to get a sense of what sort of capacity we have for planning
purposes.
On Mon, Jun 14, 2010 at 7:57 AM, Roan Kattouw <roan.kattouw(a)gmail.com>
wrote:
On a slightly related note, I strongly believe
Bugzilla exists for the
developers, not for project managers. Adding project management
features is a good thing, but that shouldn't come at great
inconvenience to the developers, especially if the benefits are as
little as Neil says they are. For this reason alone, I'm against
switching to another bug tracker for better PM support unless it's
clearly superior to BZ, both for PMs and devs.
I strongly believe that Bugzilla exists for development, not just
developers.
We are far from jettisoning Bugzilla at this point. There's plenty of
evidence to suggest we can adapt it to our needs. However, there's a
certain baseline that Bugzilla has yet to clear for project managers, and if
it can't clear it, we will need to look elsewhere, even if a migration is
only of marginal direct benefit to developers.
Having happy, productive project managers is something that is of great
benefit to developers.
On Mon, Jun 14, 2010 at 8:05 AM, Chad <innocentkiller(a)gmail.com> wrote:
+1 [to Roan]. I haven't been convinced that BZ
sucks enough or that
any particular choice given so far has been fantastic enough
to warrant the headache of migration.
I'll agree with this. My first choice is to stick with Bugzilla, assuming
we can rally a community around addressing its current deficiencies for
project management. I've gotten plenty of skeptical looks around the office
at this proposition, though. I'm going to stubbornly plow ahead in pursuit
of this goal, since we won't know whether its possible until we try.
Rob