mantisbt:roadmap_requirements
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:roadmap_requirements [2006/09/17 23:29] – Added feedback section vboctor | 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 5: | Line 5: | ||
===== Introduction ===== | ===== 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' | + | 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' |
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. | 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. | ||
Line 13: | Line 13: | ||
In Mantis versions up to 1.0.x the way to implement such a feature would be to do the following: | 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 future releases. | + | * 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. | * 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. | * Possibly implement a roadmap script that would output a Changelog like out that is based on the target release. | ||
Line 21: | Line 21: | ||
===== Database Changes ===== | ===== Database Changes ===== | ||
- | * Add a target_release | + | * **(Done)** Add a target_version |
* Add a optional target_date to the version table. | * Add a optional target_date to the version table. | ||
===== Configuration Changes ===== | ===== Configuration Changes ===== | ||
- | * Add " | + | |
- | * Add "roadmap_edit_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. | + | |
===== General Changes ===== | ===== General Changes ===== | ||
Line 33: | Line 33: | ||
* Add an issue group action to set the target release. | * Add an issue group action to set the target release. | ||
* Support this as a field in the following pages: | * Support this as a field in the following pages: | ||
- | * Report Issue page | + | * **(Done)** Report Issue page |
- | * View Issues page | + | * **(Done)** View Issues page |
* Print Issues page | * Print Issues page | ||
- | * Issue View Advanced page (eventually will be customizable through templates). | + | * **(Done)** Issue View Advanced page (eventually will be customizable through templates). |
- | * Issue Update Advanced page (eventually will be customizable through templates). | + | * **(Done)** Issue Update Advanced page (eventually will be customizable through templates). |
* CSV export | * CSV export | ||
* Excel export | * Excel export | ||
* Word export | * Word export | ||
- | | + | |
* The possible values for a target release combobox makes sense to only be the versions that don't have the released flag checked. | * The possible values for a target release combobox makes sense to only be the versions that don't have the released flag checked. | ||
* When filtering, users may want to filter on what was planned in a release which has just been released. | * When filtering, users may want to filter on what was planned in a release which has just been released. | ||
Line 48: | Line 48: | ||
===== Roadmap Page ===== | ===== Roadmap Page ===== | ||
- | * A Roadmap page should be added. | + | * **(Done)** A Roadmap page should be added. |
- | * Add Roadmap option to the main menu. | + | * **(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. | * 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. | ||
- | * Similar to the Changelog page, this page should support "All Projects" | + | * **(Done)** Similar to the Changelog page, this page should support "All Projects" |
- | * Similar to the Changelog page, it should be possible to directly link to this page from a website. | + | * **(Done)** Similar to the Changelog page, it should be possible to directly link to this page from a website. |
- | * 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. | + | * **(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. |
- | * Use custom functions to allow users to override them and determine the formatting to be used in presenting an issue. | + | * **(Done)** Use custom functions to allow users to override them and determine the formatting to be used in presenting an issue. |
- | * The default formatting should show the following information for each issue grouped by the target release: | + | * **(Done)** The default formatting should show the following information for each issue grouped by the target release: |
* Issue Id | * Issue Id | ||
* Status | * Status | ||
* Handler | * Handler | ||
* Summary | * Summary | ||
+ | * Category | ||
* For each release title the following information should be included: | * For each release title the following information should be included: | ||
- | * Release name | + | * **(Done)** Release name |
* Target date (if supplied) | * Target date (if supplied) | ||
- | * Issues done (i.e. 20 issues resolved out of 30 planned). | + | * **(Done)** Issues done (i.e. 20 issues resolved out of 30 planned). |
- | * Release description (if not empty). | + | * **(Done)** Release description (if not empty). |
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
===== Feedback ===== | ===== Feedback ===== | ||
Please add your comments and feedback in this section. | 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"? | ||
+ | * 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 " | ||
+ | |||
+ | * 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) | ||
mantisbt/roadmap_requirements.1158550180.txt.gz · Last modified: 2008/10/29 04:31 (external edit)