327861 - Roadmap/Milestone handling and visualization

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement)

Description

[vguna]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

There was a time, where I had to decide which bugtracking tool I should use for developing. I had to choose between Trac and Bugzilla. Bugzilla did it, but I missed that lovely neat roadmap/milestone planning interface that Trac has.

So I started to implement that roadmap feature into Bugzilla. It's a small piece of cgi that utilitize an additional table which holds the milestone informationen. So for every milestone (already implemented in bugzilla) you can
define a target date which will be visualized in different colors (green, orange (only n-days left), red (running late > target_date) etc.
The progress depending on the milestone + open/closed bugs is also displayed in a trac fashion way.
So all I wanted to ask is, will such a feature be implemented in bugzilla in future? Or, is someone interested in my sourcecode to extend it and probably add it to the bugzilla development line?
There're some things to enhance... changing dates, milestone description etc. is all done in the database directly - this should be handled through a webpage in future.
Tell me what you think.



Reproducible: Always

Comment 1

[vguna]

Attachment: Roadmap already implemented

This is a screenshot of the roadmap/milestone planning that I implemented so far. Looks like the Trac pendant and works for me.

Comment 2

[Frédéric Buclin]

That's a point we discussed today at our Bugzilla meeting, and we want some way to use roadmaps directly in Bugzilla. We probably requires two tables:

'roadmaps'
id integer Primary Key Not Null Auto-increment
name varchar(100) unique not null
...

'roadmap_bug_map' (or something like that)
roadmap_id integer not null (references roadmaps.id)
bug_id integer not null (references bugs.bug_id)
...

and we probably want two new .cgi's: editroadmaps.cgi and show_roadmap.cgi, as well as a new system group, 'edit_roadmaps'. Editing roadmaps will require edit_roadmaps privileges.

Comment 3

[Michael]

I was going to suggest something similar, in addition to what's already been proposed, it would be useful if there was the possibility to mark bugs as "roadmap candidates".
Also, there could be some sort of score calculated that automatically suggests certain bugs as potential roadmap candidates (i.e. based on priority,severity,votes,dependencies that would be resolved etc.)

Comment 4

[Frédéric Buclin]

(In reply to comment #2)
> and we probably want two new .cgi's: editroadmaps.cgi and show_roadmap.cgi, as
> well as a new system group, 'edit_roadmaps'. Editing roadmaps will require
> edit_roadmaps privileges.

By discussing this topic a bit more on IRC, we finally came to the conclusion that creating new .cgi's was not the best thing to do. What we would prefer is to improve showdependencytree.cgi and include deadlines in it (the deadlines defined in show_bug.cgi which you can see when you are in the timetracking group). This also means we probably don't want to create new SQL tables.

Comment 5

[Michael]

if the idea of providing a bugZilla based roadmap is pursued, it would probably make sense to consider providing a new bug type for "tasks" by default, too?

Comment 6

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 8

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 10

[Frédéric Buclin]

See also screenshots from bug 359086. I think the screenshot suggested in this bug could incorporate links to display relevant bugs per milestone, as suggested in bug 359086.

Comment 11

[Mr. Gecko]

I want to say that this would be an awesome idea and I would love to see this happen. I am in a similar situation as vguna as I feel like Bugzilla is the best bug reporter for the user and offers a lot more power than trac, but that roadmap/milestone overview in trac is very attractive and would be neat to have in Bugzilla. Now it shouldn't be too hard to implement this as far as I hear and it would be great for people who is wondering what is planned for the software that they are looking at and the progress of bugs being fixed. I would work on this if I had the time to, but I don't. Maybe if nobody tries to take the position of adding this in, I'll give it a try as a project after the ones I'm currently working on.

Comment 12

[Jeff]

Just realized how long this bug/feature has been on the books and I just wanted to add that I also would like to see this feature and the lack of features such as a roadmap is one main reason that I've been seriously considering converting the Bugzilla installations that I manage over to a competing product. Originally I liked trac for it's roadmap but more recently it's looking like I'm going to be considering BugNET which also has a roadmap feature, hierarchical components, SQL Server and better IIS support as well as many other features that are increasingly important to me.

I guess what I'm looking for is whether somebody can answer why features like this don't seem to move forward in Bugzilla. If the answer is that nobody had the time to design the ideal roadmap then why was the original proposed version by vguna never proposed or offered as a an optional officially supported extension that would evolve along with Bugzilla.

As somebody who is becoming disenchanted with the progress in the Bugzilla project I can say that at least an effort to build a more vibrant community for creating extensions to support features like this roadmap would be a big improvement.

Comment 13

[Dave Miller [:justdave]]

Bugzilla's back end code used to be a mess. We spent about 5 years ignoring a lot of feature requests because they'd be really hard to implement within the way Bugzilla was built at the time, stalling to get the back-end rewrite done which would make such things much easier to implement in the future.  This bug was filed (and last discussed) during that rewrite, which is probably why it's sat untouched.  That rewrite was mostly done about a year ago, and we've been getting a great number of new features and major bugs fixed in the last year or so that have sat around forever.  I suspect this is one of those cases that, now that we have easy ways to implement this kind of stuff, people just needed a reminder that it was sitting here waiting (which these last few comments have probably accomplished).

Comment 14

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Comment 15

[Graham Perrin]

Hello 2012. 2021 calling.

Also ding dong, bug 761526 comment 5 …