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/11/18 14:13] – Update the requirements to reflect progress. 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 21: | Line 21: | ||
===== Database Changes ===== | ===== Database Changes ===== | ||
- | * **(Done)** 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. | ||
Line 27: | Line 27: | ||
* **(Done)** Add " | * **(Done)** 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 52: | Line 52: | ||
* 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. | ||
* **(Done)** 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. |
* **(Done)** 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. | ||
* **(Done)** 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: | ||
Line 65: | Line 65: | ||
* Target date (if supplied) | * Target date (if supplied) | ||
* **(Done)** 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.1163877226.txt.gz · Last modified: 2008/10/29 04:31 (external edit)