Edgewall Software

Ticket #364 (closed enhancement: fixed)

Opened 5 years ago

Last modified 6 weeks ago

New 'Roadmap' module

Reported by: daniel Owned by: cmlenz
Priority: normal Milestone: 0.8
Component: roadmap Version: 0.7
Severity: normal Keywords:
Cc:

Description

cmlenz proposes an excellent addition, a Roadmap module.

Full description at:

http://www.informatik.fh-wiesbaden.de/~clenz001/misc/trac_roadmap/

Attachments

Change History

Changed 5 years ago by cmlenz

  • owner changed from jonas to cmlenz
  • status changed from new to assigned

Changed 5 years ago by cmlenz

  • version changed from 0.6.1 to 0.7

Okay, here's my iteration plan for this story (very rough):

1. Basic roadmap module implementation

2. Add milestone management/administration functions

  • Add a 'Create New Milestone' action to the roadmap view
  • Add 'Edit This Milestone' and 'Delete This Milestone' actions to the milestone view
  • Implement a form that handles milestone creation and editing

3. Introduce milestone IDs and descriptions

  • Extend the database schema of the milestone table so that the primary key is an integer 'id' column, and add a 'description' text column.
  • Change the ticket table, and maybe the ticket_change table, so that milestones are referenced by ID instead of their name (not sure about that yet, though)
  • If the point above is done, adjust the ticket form and form handling to reference milestones by ID
  • Add/modify a database upgrade script (source:trunk/trac/upgrades/db4.py)
  • Extend the form for editing milestones so that a wiki-formatted description can be entered/modified.
  • Milestone URLs now contain the ID instead of the name, for example /trac/milestone/11

4. Investigate/implement further enhancements:

  • Add linking to reports that list the open/active tickets for a milestone (and optionally component)
  • Add a "Show Past Milestones" action to the roadmap view (by default only non-completed milestones are displayed)
  • Anything else?

Changed 5 years ago by cmlenz

A part of iteration 2 that I forgot would be to change or possibly even remove functionality in trac-admin that is related to milestone management.

Changed 5 years ago by cmlenz

First iteration was checked in with [577].

Changed 5 years ago by daniel

A few ideas:

  • Completed milestones could be pushed to the bottom of the page. Maybe not a good idea considering the chronological order/nature of milestones.
  • Completed milestones could be displayed differently; e g just say something like "Milestone completed" rather than showing all tickets, progressbar and stuff. Saves some real-estate.

Changed 5 years ago by cmlenz

In iteration 1 you should actually never see completed milestones. What is shown are all milestones that either have (a) no date set or (b) a date that is in the future. So the definition of a "completed" milestone is that its date has been reached.

Displaying completed/past milestones is planned for iteration 4.

Changed 5 years ago by jamesm@…

Ticket #440 touches on some things that are related to Roadmap.

Changed 5 years ago by balk@…

I'd recommend changing the header "percent completed" to "tickets completed". "Percent completed" doesn't really say percentage of what. And it's obvious it's percentage from the percentage-sign anyway.

Changed 5 years ago by cmlenz

  • component changed from general to roadmap

Changed 5 years ago by cmlenz

Iteration 2 status is tracked by #446.

Changed 5 years ago by cmlenz

I've been thinking about the URL addressing scheme for milestones. The plan for iteration 3 is to introduce integer IDs as primary keys for the milestone table. However, that results in meaningless URLs.

Currently, if milestones are named in a URL-compatible manner (which is not being checked yet), you get URLs such as

http://projects.edgewall.com/trac/milestone/0.7.1

which is quite nice I believe. Migrating to integer IDs would mean losing this URL readability.

An alternative to introducing an integer ID would be to keep the milestone name as the primary key and use it in the URL, but to add a 'Title' or 'Display name' column that could take a longer name that does not need to be URL-compatible (such as 0.7 'Fulci').

The downside of that approach would be URL persistence: if a milestone gets renamed (say from 0.7.1 to 0.7.1.0 or whatever), then links to the old milestone would get 404s. There would be ways to avoid that (by remembering the old names and causing permanent redirects), but that could get messy.

Any thoughts?

Changed 5 years ago by jamesm@…

I realize its ugly, but I think that the ability to link to the milestone outweighs the benefits of a pretty-url. I would say go with a fixed integer (like tickets do) and let the user assign a name/descrption to the fixed integer. I think that the linking throughout Trac/outside Trac is more important.

If #364 is for tickets and [400] is for Changesets, what notation will milestones use? [M1]?

Changed 4 years ago by cmlenz

  • status changed from assigned to closed
  • resolution set to fixed

The roadmap module is pretty much complete now, as of [852]. Remaining shortcomings should go in separate tickets.

Add/Change #364 (New 'Roadmap' module)

Author



Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
to The owner will change from cmlenz. Next status will be 'closed'
 
Note: See TracTickets for help on using tickets.