Differences

This shows you the differences between two versions of the page.

--- mantisbt:roadmap_requirements [2008/05/19 16:18] – SneakyWho_am_i
+++ mantisbt:roadmap_requirements [2011/11/16 07:29] (current) – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol
@@ Line 1: / Line 1: @@
+====== Roadmap Requirements ======
+**Author**: Victor Boctor
+===== Introduction =====
+Mantis has the changelog feature which is very good at tracking the work that has already been done.  However, out of the box, Mantis doesn't have a feature that can help with the planning work and associating it with future versions (or milestones) on the roadmap.  The aim of this feature is to achieve that.
+A point that is worth mentioning is that target release will end up being used to plan all issues, whether they are features or bugs.  Hence, there will be situations where the project manager will want to apply a bug fix to a couple of branches and hence a couple of releases.  In order to keep things simple the recommended approach for that is to clone the bug and assign each one to the target release.  It is expected that all the analysis, notes, etc will be associated with the original issue.  The cloned issue will just be used to track / assign the work.  In some scenarios, there may be a different fix for the issue per branch (a quick and low risk one vs. a proper fix).  In this case there may be some analysis per issue.  Also this help with tracking the rest of the process including testing, re-opening of issues, etc.
+===== Current Approach =====
+In Mantis versions up to 1.0.x the way to implement such a feature would be to do the following:
+   * Create a target_release custom field of type enum and possible value dynamically populated with project versions.
+   * Use filters to filter by Target Release custom field to track the planned work.
+   * Possibly implement a roadmap script that would output a Changelog like out that is based on the target release.
+For users who already use this approach, they will be able to move the current values of the target release custom field to the new native custom field with an already existing admin script.
+===== Database Changes =====
+   * **(Done)** Add a target_version field to the issue that is the same type as version and fixed_in_version.  This field can be left empty of not specified.  It can also be added to the custom field list (see [[customizing_columns_in_view_issues_page]]).
+   * Add a optional target_date to the version table.  This allows the project manager to set a deadline for the release.
+===== Configuration Changes =====
+    * **(Done)** Add "roadmap_view_threshold" which is to be set to the threshold required for a user to be able to view the Roadmap.  The default value should be VIEWER.  If a user can't see the roadmap, then such user shouldn't be able to view, edit or filter by target release.  If set to NOBODY, then the Roadmap / target release changes are all hidden/disabled.
+    * **(Done)** Add "roadmap_update_threshold" which is to be set to the threshold required for a user to be able to set/change the value of the target release.  The default value should be DEVELOPER.
+===== General Changes =====
+   * Add an issue group action to set the target release.  This allows users to select multiple issues in the View Issues page and assign them all to a target release.
+   * Support this as a field in the following pages:
+     * **(Done)** Report Issue page
+     * **(Done)** View Issues page
+     * Print Issues page
+     * **(Done)** Issue View Advanced page (eventually will be customizable through templates).
+     * **(Done)** Issue Update Advanced page (eventually will be customizable through templates).
+     * CSV export
+     * Excel export
+     * Word export
+   * **(Done)** Ability to filter by the target release.
+   * The possible values for a target release combobox makes sense to only be the versions that don't have the released flag checked.  However, there are two issues with that:
+     * When filtering, users may want to filter on what was planned in a release which has just been released.  Ideas are welcome for possible solutions to this issue.
+     * When updating an issue, if the current value of the target release is not one of the options then the field will select the first entry and will update the record to the wrong value when saved.  The fix for this is to always show the current value + whatever value that matches the criteria.
+===== Roadmap Page =====
+   * **(Done)** A Roadmap page should be added.  This roadmap page should look and behave like the current changelog page but it should reflect on releases that are not yet market as released.
+   * **(Done)** Add Roadmap option to the main menu.
+   * If an issue has a fixed_in_release and target_release both set and status is fixed, then the roadmap should use the fixed_in_release field.  Hence, if such release is not yet released, then it will appear under this release rather than the original target_release.
+   * **(Done)** Similar to the Changelog page, this page should support "All Projects" as well as specific project.
+   * **(Done)** Similar to the Changelog page, it should be possible to directly link to this page from a website.  It should be possible to specify the project_id as a get parameter.
+   * **(Done)** Users should only see the issues that are visible to them.  Hence, private issues should not be visible to users who don't have such access.  Anonymous users should only be able to access it if such access is allowed.
+   * **(Done)** Use custom functions to allow users to override them and determine the formatting to be used in presenting an issue.
+   * **(Done)** The default formatting should show the following information for each issue grouped by the target release:
+     * Issue Id
+     * Status
+     * Handler
+     * Summary
+     * Category
+   * For each release title the following information should be included:
+     * **(Done)** Release name
+     * Target date (if supplied)
+     * **(Done)** Issues done (i.e. 20 issues resolved out of 30 planned).
+     * **(Done)** Release description (if not empty).
+===== Feedback =====
+Please add your comments and feedback in this section.
+  * add the progress bar to roadmap_page.php like trac. (seiji)
+  * Why does there has to be an additional field that becomes obsolete after the bug is resolved (and the value is copied into "fixed in version"? We renamed "fixed in version" to "target version", use it for both purposes and are quite happy with it. (polzin)
+             * That sounds like a good idea. I will be keeping both values though. It is clutter but I like it how it is. One box is for what SHOULD happen, and the other is for what DOES happen. So for me, at least, it is a way to see if we are meeting our goals. My main problem is with the wiki page itself. It could probably use redoing to some extent (for example, database changes? The method for adding the field to the reporting screen is no longer really applicable...) (SneakyWho_am_i)
+  * maybe also add a field to set a version as "private/public" to add milestones/planned releases for developers, without showing them publicly yet (rolf)
+  * adding an optional target_date to the version table seems redundant. Using the current date_order field allows for all the flexibility required to implement version due dates. To implement due dates at the version level use the date_order field as the target date until a version is released. Then display the date next to the version title in the roadmap. If the current date exceeds the date_order field and the version is not released have the roadmap page highlight the projected released date in red or some other color to show the due date has passed. If wanted it would be trivial to add the number of days the version is late by appending a negative number to the end of the due date. (herringm)