Hi everyone,
Sorry for the email length here. Here's my quick summary: * Trying to figure out how to do good project management on Bugzilla, working with the Bugzilla community to juice it up * Failing that, we'd like to migrate off of it. Leading candidate: Redmine * Wiki page: http://www.mediawiki.org/wiki/Tracker/PM_tool
And now, the (much) longer version:
As you probably recall, Priyanka has been investigating our use of Bugzilla, and investigating whether or not it makes sense to keep using it, or migrate to something else. I'm helping her out with that evaluation now, and here's where we're at.
We really want to have well-integrated issue management (both feature requests and bugs) along with project management.
We've informally narrowed the choices down to 1) staying with Bugzilla, or 2) migrating to Redmine. I say "informally" because it's not as though there's been any formal consensus gathering process of any sort, and we know we need to really need to involve everyone in this process.
Staying on Bugzilla would obviously be the least disruptive choice, and we'd prefer to stay with the devil we know rather than find out what Redmine or some other tracker doesn't have after a migration.
However, looking at Bugzilla, as currently configured, from the point of view of a project manager, it really doesn't work very well. It's very difficult to provide a birds-eye view of how a project is progressing without building a separate manually-maintained wiki page with a project plan on it. While it seems possible to *cope* as a project manager with Bugzilla, it doesn't seem like the kind of tool that a project manager could grow to love, at least not how it exists now.
Redmine has time management built in, and is pretty clearly designed as a project management tool generally. By way of example, here's the roadmap for the Redmine project itself: http://www.redmine.org/projects/redmine/roadmap
It seems to favor old-school time management (with Gantt charts having better support than Burndown charts), but it looks like a versatile enough tool to adapt to many different project management styles. Most importantly, it has sensible defaults that we can count on others also building upon.
Now, as I've alluded to, the problem may just be with our configuration of Bugzilla, which is pretty narrowly focused on just tracking bugs. We reached out to the Bugzilla developers on IRC, and I'm planning to follow up on the Bugzilla newsgroup: http://groups.google.com/group/mozilla.support.bugzilla/
As with pretty much any mature piece of infrastructure software, it is possible to extend it. For example, Max Kanat-Alexander pointed out the new extension interface in the latest version of Bugzilla, and believes it would be reasonably simple now to create a roadmap plugin. That's not the only thing Bugzilla is lacking to be a really good project management tool, so we'll need a little more than "add roadmaps" to get us where we ultimately want to be, but having that functionality is a good start.
In order for Bugzilla to be a viable option for project management, the Bugzilla team would need to demonstrate that they're serious about creating something competitive in this area. Redmine isn't the only competition that appears to do better; JIRA is also better in this regard. While we may be the ones asking most directly right now, I've gotta believe that many other Bugzilla users are either hitting the same wall we are, or know something that we don't.
Here's what we're planning to do: 1. Engage the Bugzilla community much more seriously about project management. Engage the Firefox developers to find out how they're making it work for them, as well as other large projects (e.g. perhaps GNOME). 2. Simultaneously engage the Redmine community and generally evaluate Redmine. Make sure we understand a lot better the good and the bad with it. For example, it appears on the surface that the query abilities aren't as sophisticated. We'll need to understand if that's going to be a problem for us. 3. If it looks like Bugzilla is on a rapid enough trajectory to becoming a great project management tool (with or without our help), then we figure out how to make that process go as quickly as possible. 4. If it looks like Bugzilla is not going to get there without an all-too-heroic effort on our part, or it looks like one of the alternatives is SO compelling that we really should make a switch, then we'll be floating a migration plan with you all.
Here's the web page that discusses this: http://www.mediawiki.org/wiki/Tracker/PM_tool
On that page, we get into some more detail about the pros and cons of each of the tools.
I realize that most of the readers on this list probably are not project management tool connoisseurs, and you're probably more interested in Bugzilla for its bug tracking ability. That said, there's probably a significant number of you that want to be more in-the-loop about what WMF staff developers are up to. Having access to the tool we use for scheduling/planning will give you more visibility.
So, here's what I'm hoping you all can help out with:
1. Take a really good look at Redmine, and see if you'd love/hate/be indifferent to a migration to that tool 2. Help with the process of fleshing out requirements/nice-to-haves on the wiki page above. 3. Help engage both the Bugzilla and Redmine communities if you've got an interest in this topic.
Does this all seem reasonable to everyone? Let us know what you think.
Thanks! Rob
On Mon, Jun 14, 2010 at 11:29 AM, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone,
Sorry for the email length here. Here's my quick summary:
- Trying to figure out how to do good project management on Bugzilla,
working with the Bugzilla community to juice it up
- Failing that, we'd like to migrate off of it. Leading candidate: Redmine
- Wiki page: http://www.mediawiki.org/wiki/Tracker/PM_tool
fwiw, I added a lot of time/project-management functionality to my Bugzilla when I was using it in a commercial project. Some of the desired functionality was already available as patches on bugzilla.mozilla.org; I added more, and most of my patches will be available on bugzilla.mozilla.org. All of those patches are probably bitrotten. I haven't looked at how far the bugzilla codebase has changed since 2002, but I would be surprised if it was difficult to rebase these patches.
For example, on mw:Tracker/PM_tool, one dot point is the separation of tasks, features, etc. This is bug 9412.
https://bugzilla.mozilla.org/show_bug.cgi?id=9412
I'd be happy to work on a few of these in a few weeks time.
-- John Vandenberg
On Sun, Jun 13, 2010 at 7:49 PM, John Vandenberg jayvdb@gmail.com wrote:
fwiw, I added a lot of time/project-management functionality to my Bugzilla when I was using it in a commercial project. Some of the desired functionality was already available as patches on bugzilla.mozilla.org; I added more, and most of my patches will be available on bugzilla.mozilla.org. All of those patches are probably bitrotten. I haven't looked at how far the bugzilla codebase has changed since 2002, but I would be surprised if it was difficult to rebase these patches. [...] I'd be happy to work on a few of these in a few weeks time.
Nice! I would very much love to have your help with this.
The main thing I'd like to ensure with any effort is that we have, in the end, a reasonably mainstream implementation. Project management is hardly a niche application for an issue tracker, so I'm going to be skeptical of approaches that require us to patch the base implementation or run plugins that few other sites are using. With a concerted effort, we should be able to drum up interest in making this standard functionality.
What "standard functionality" means is somewhat subjective here. From an architectural perspective, it'd be perfectly fine if that functionality is running as an extension rather than as part of the core, so long as those extensions are well-integrated and considered part of the standard suite. However, if at the end of this process, the answer from the Bugzilla team/everyone else is "sure you can do project management...there's at least 5 roughly identical plugins on github that sorta do what you need, I'm sure you can find something and stitch it together", then I think I'd rather migrate to Redmine.
So, my question for you: what sort of role would you like? a) Pitch in on a project lead by someone else b) Lead an effort for providing and sustaining general purpose project management functionality in Bugzilla c) Something else
Both a) and b) are necessary and useful, so either of those answers would make me very happy. For all of the wordiness of the last email, one thing I probably didn't make clear: Priyanka and I are willing to lead a short-term effort to get better project tracking in Bugzilla, and we'll put in a little extra if it looks likely we can catalyze a long-term effort, but a long-term leader in the Bugzilla community is going to need to emerge quickly for us to be comfortable sticking with Bugzilla.
Rob
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?
I sympathize but I'm skeptical about exactly how much a tool alone can improve things.
I'm also skeptical of time tracking, period. It involves bookkeeping that is secondary to everyone's primary goals on any given day. And if you do it inconsistently, it becomes worse than useless. (I don't see any of the top projects on Redmine that seem to be using time tracking seriously.)
In my experience, developer practice and communication is what makes projects stay on time. Choice of issue tracker is nearly irrelevant.
That said, I can totally understand the desire for better measurement, or tools like Gannt charts.
On 2010-06-13 6:29 PM, Rob Lanphier wrote:
Hi everyone,
Sorry for the email length here. Here's my quick summary:
- Trying to figure out how to do good project management on Bugzilla,
working with the Bugzilla community to juice it up
- Failing that, we'd like to migrate off of it. Leading candidate: Redmine
- Wiki page: http://www.mediawiki.org/wiki/Tracker/PM_tool
And now, the (much) longer version:
As you probably recall, Priyanka has been investigating our use of Bugzilla, and investigating whether or not it makes sense to keep using it, or migrate to something else. I'm helping her out with that evaluation now, and here's where we're at.
We really want to have well-integrated issue management (both feature requests and bugs) along with project management.
We've informally narrowed the choices down to 1) staying with Bugzilla, or 2) migrating to Redmine. I say "informally" because it's not as though there's been any formal consensus gathering process of any sort, and we know we need to really need to involve everyone in this process.
Staying on Bugzilla would obviously be the least disruptive choice, and we'd prefer to stay with the devil we know rather than find out what Redmine or some other tracker doesn't have after a migration.
However, looking at Bugzilla, as currently configured, from the point of view of a project manager, it really doesn't work very well. It's very difficult to provide a birds-eye view of how a project is progressing without building a separate manually-maintained wiki page with a project plan on it. While it seems possible to *cope* as a project manager with Bugzilla, it doesn't seem like the kind of tool that a project manager could grow to love, at least not how it exists now.
Redmine has time management built in, and is pretty clearly designed as a project management tool generally. By way of example, here's the roadmap for the Redmine project itself: http://www.redmine.org/projects/redmine/roadmap
It seems to favor old-school time management (with Gantt charts having better support than Burndown charts), but it looks like a versatile enough tool to adapt to many different project management styles. Most importantly, it has sensible defaults that we can count on others also building upon.
Now, as I've alluded to, the problem may just be with our configuration of Bugzilla, which is pretty narrowly focused on just tracking bugs. We reached out to the Bugzilla developers on IRC, and I'm planning to follow up on the Bugzilla newsgroup: http://groups.google.com/group/mozilla.support.bugzilla/
As with pretty much any mature piece of infrastructure software, it is possible to extend it. For example, Max Kanat-Alexander pointed out the new extension interface in the latest version of Bugzilla, and believes it would be reasonably simple now to create a roadmap plugin. That's not the only thing Bugzilla is lacking to be a really good project management tool, so we'll need a little more than "add roadmaps" to get us where we ultimately want to be, but having that functionality is a good start.
In order for Bugzilla to be a viable option for project management, the Bugzilla team would need to demonstrate that they're serious about creating something competitive in this area. Redmine isn't the only competition that appears to do better; JIRA is also better in this regard. While we may be the ones asking most directly right now, I've gotta believe that many other Bugzilla users are either hitting the same wall we are, or know something that we don't.
Here's what we're planning to do:
- Engage the Bugzilla community much more seriously about project
management. Engage the Firefox developers to find out how they're making it work for them, as well as other large projects (e.g. perhaps GNOME). 2. Simultaneously engage the Redmine community and generally evaluate Redmine. Make sure we understand a lot better the good and the bad with it. For example, it appears on the surface that the query abilities aren't as sophisticated. We'll need to understand if that's going to be a problem for us. 3. If it looks like Bugzilla is on a rapid enough trajectory to becoming a great project management tool (with or without our help), then we figure out how to make that process go as quickly as possible. 4. If it looks like Bugzilla is not going to get there without an all-too-heroic effort on our part, or it looks like one of the alternatives is SO compelling that we really should make a switch, then we'll be floating a migration plan with you all.
Here's the web page that discusses this: http://www.mediawiki.org/wiki/Tracker/PM_tool
On that page, we get into some more detail about the pros and cons of each of the tools.
I realize that most of the readers on this list probably are not project management tool connoisseurs, and you're probably more interested in Bugzilla for its bug tracking ability. That said, there's probably a significant number of you that want to be more in-the-loop about what WMF staff developers are up to. Having access to the tool we use for scheduling/planning will give you more visibility.
So, here's what I'm hoping you all can help out with:
- Take a really good look at Redmine, and see if you'd love/hate/be
indifferent to a migration to that tool 2. Help with the process of fleshing out requirements/nice-to-haves on the wiki page above. 3. Help engage both the Bugzilla and Redmine communities if you've got an interest in this topic.
Does this all seem reasonable to everyone? Let us know what you think.
Thanks! Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/6/14 Neil Kandalgaonkar neilk@wikimedia.org:
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?
I sympathize but I'm skeptical about exactly how much a tool alone can improve things.
I'm also skeptical of time tracking, period. It involves bookkeeping that is secondary to everyone's primary goals on any given day. And if you do it inconsistently, it becomes worse than useless. (I don't see any of the top projects on Redmine that seem to be using time tracking seriously.)
In my experience, developer practice and communication is what makes projects stay on time. Choice of issue tracker is nearly irrelevant.
That said, I can totally understand the desire for better measurement, or tools like Gannt charts.
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.
Roan Kattouw (Catrope)
On Mon, Jun 14, 2010 at 10:57 AM, Roan Kattouw roan.kattouw@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.
Roan Kattouw (Catrope)
+1. 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.
-Chad
On 2010-06-14 7:57 AM, Roan Kattouw wrote:
that shouldn't come at great inconvenience to the developers, especially if the benefits are as little as Neil says they are.
Well, to be clear: I have an opinion against time tracking as a tool for product management or estimation, especially if it involves extra bookkeeping. From what I can tell, Redmine does work like that.
That said, Redmine might be better than Bugzilla for a variety of other reasons. Or, maybe time tracking is really great when done right and I just haven't ever seen that yet. When I say skeptical, I just mean that I would like to see evidence first.
If it really makes the PMs' lives much better, we should definitely consider it. I agree with you that developers should be considered the primary 'customer' of the tool though.
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@wikimedia.orgwrote:
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@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@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
Are there any public Bugzilla and Subversion dumps? I'd like to download them and experiment with BZ/RM, but I need real data for it (and don't really like the idea of downloading it manually).
--vvv
Victor Vasiliev wrote:
Are there any public Bugzilla and Subversion dumps? I'd like to download them and experiment with BZ/RM, but I need real data for it (and don't really like the idea of downloading it manually).
--vvv
There are subversion dumps at http://svn.wikimedia.org/dumps/ I am not aware of any bugzilla dump, although I'd like to be able to play with one.
http://project2.wikimedia.org/ is a Redmine instance with a data that was migrated from bugzilla.wikimedia.org The data is a few months old, I didn't get around to updating it recently. You will have to use the "forgot password" option on your bugzilla username or create a new one. Also it does not receive emails yet.
This instance was setup for initial evaluation and has not been rigorously tested, so let me know if somethign is badly broken.
-p
On 6/14/10 9:44 AM, Victor Vasiliev wrote:
Are there any public Bugzilla and Subversion dumps? I'd like to download them and experiment with BZ/RM, but I need real data for it (and don't really like the idea of downloading it manually).
--vvv
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Priyanka Dhanda wrote:
http://project2.wikimedia.org/ is a Redmine instance with a data that was migrated from bugzilla.wikimedia.org The data is a few months old, I didn't get around to updating it recently. You will have to use the "forgot password" option on your bugzilla username or create a new one. Also it does not receive emails yet.
This instance was setup for initial evaluation and has not been rigorously tested, so let me know if somethign is badly broken.
-p
Defect #1: Where is the "Report a bug" feature?
#2 - The member list at http://project2.wikimedia.org/projects/mediawiki seems needlessly long.
On Sun, Jun 13, 2010 at 6:29 PM, Rob Lanphier robla@wikimedia.org wrote:
- Help engage both the Bugzilla and Redmine communities if you've got an
interest in this topic.
Speaking of this, I've sent out mails to both the Bugzilla folks and the Redmine folks: Bugzilla: http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread... Redmine: http://www.redmine.org/boards/1/topics/15098
Rob
wikitech-l@lists.wikimedia.org