Edgewall Software
Modify

Opened 15 years ago

Closed 15 years ago

Last modified 11 years ago

#364 closed enhancement (fixed)

New 'Roadmap' module

Reported by: daniel Owned by: Christopher Lenz
Priority: normal Milestone: 0.8
Component: roadmap Version: 0.7
Severity: normal Keywords:
Cc: Branch:
Release Notes:
API Changes:

Description

cmlenz proposes an excellent addition, a Roadmap module.

Full description at:

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

Attachments (0)

Change History (13)

comment:1 by Christopher Lenz, 15 years ago

Owner: changed from Jonas Borgström to Christopher Lenz
Status: newassigned

comment:2 by Christopher Lenz, 15 years ago

Version: 0.6.10.7

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

  1. Basic roadmap module implementation
  1. 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
  1. 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
  1. 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?

comment:3 by Christopher Lenz, 15 years ago

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.

comment:4 by Christopher Lenz, 15 years ago

First iteration was checked in with [577].

comment:5 by daniel, 15 years ago

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.

comment:6 by Christopher Lenz, 15 years ago

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.

comment:7 by jamesm@…, 15 years ago

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

comment:8 by balk@…, 15 years ago

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.

comment:9 by Christopher Lenz, 15 years ago

Component: generalroadmap

comment:10 by Christopher Lenz, 15 years ago

Iteration 2 status is tracked by #446.

comment:11 by Christopher Lenz, 15 years ago

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?

comment:12 by jamesm@…, 15 years ago

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]?

comment:13 by Christopher Lenz, 15 years ago

Resolution: fixed
Status: assignedclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.