View Issue Details

IDProjectCategoryView StatusLast Update
0008800mantisbtreportspublic2017-01-24 11:40
ReporterBorszczuk Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Product Version1.1.1 
Target VersionFixed in Version 
Summary0008800: Roadmap "gauges" shall be drawin using different colors depending on the progress value

Roadmap "gauges" shall be drawin using different colors depending on the progress value. I.e.:

Light Red for 0%-30%
Dark Red for 31%-50%
Yellow for 51%-75%
Light green or #a7e318) for 76%-99%
Dark Green for 100%

TagsNo tags attached.


2008-01-25 13:00


colors-2.patch (2,198 bytes)
diff -r mantis-1.1.1/config_defaults_inc.php mantis-1.1.1-borszczuk/config_defaults_inc.php
> 	# --- Roadmap progress colors ----
> 	#
> 	# percentage: 0, 30, 50.. - start percentage at which given colors shall be used
> 	#             you add as many as you want (for any percentage between 0-100). So
> 	#             adding entry with key 44 you set that these colors shall be used
> 	#             starting from 44% (inclusive) to the next threshold percentage value.
> 	#             You can also remove as many as you want but entry for 0% HAVE TO exists
> 	#             for fallback purposes!
> 	#
> 	#     colors: 'bg' - background color, 'fg' - foreground color
> 	#
> 	#     use 'empty' color (i.e. 'fg'=>'') to disable fg color.
> 	#
> 	$g_roadmap_progress_colors = array(	  0	=> array( 'bg'=>'#ac0f0f',	'fg'=>'white' ),
> 										 30	=> array( 'bg'=>'#f9a8a8',	'fg'=>'black' ),
> 										 50 => array( 'bg'=>'#e7c93e',	'fg'=>'black' ),
> 										 75 => array( 'bg'=>'#a8f65c',	'fg'=>'black' ),
> 										 90 => array( 'bg'=>'#41cd3e',	'fg'=>'black' ),
> 										100 => array( 'bg'=>'#038500',	'fg'=>'white' )
> 									);
diff -r mantis-1.1.1/roadmap_page.php mantis-1.1.1-borszczuk/roadmap_page.php
> 				# we do ksort() to avoid problems if someone screw the order editing...
> 				$t_color_array =  config_get('roadmap_progress_colors') ;
> 				ksort( $t_color_array );
> 				# let's find closes match...
> 				$t_bg = $t_fg = '';
> 				foreach( $t_color_array AS $t_key=>$t_val ) {
> 					if( $t_progress >= $t_key ) {
> 						$t_bg = $t_val['bg'];
> 						$t_fg = $t_val['fg'];
> 					} else {
> 						break;
> 					}
> 				}
> 				# let's build color styles here...
> 				$t_color_styles = '';
> 				if( $t_bg != '' )
> 					$t_color_styles .= sprintf('background: %s;', $t_bg);
> 				if( $t_fg != '' )
> 					 $t_color_styles .= sprintf('color: %s;', $t_fg);
< 				echo '  <span class="bar" style="width: ' . $t_progress . '%;">' . $t_progress . '%</span>';
> 				printf(' <span class="bar" style="width: %1$s%%;%2$s">%1$s%%</span>', $t_progress, $t_color_styles );
< ?>
\ No newline at end of file
> ?>
colors-2.patch (2,198 bytes)


2008-01-27 15:33

manager   ~0016849

I am wondering whether colors should be used to reflect progress percentage or whether the project is on track or not. I believe that the project can be great while progress is 0 (assuming we are on day 1) and green when we are on 50% (if we are half way through the time allocated for the project).

I wonder what others think?!



2008-01-28 12:51

reporter   ~0016862

I would love to be able to set a target deadline for a project's target release and then have the gauge change colors to indicate degree of slippage.



2008-01-30 03:26

manager   ~0016882

@nurikabe, the complexity associated with your proposal is that for progress relative to time to be accurate, the following has to been taken into consideration:

  1. Calendar - working days, working hours - note that this can change per resource.
  2. Availability of resources on project - can change based on date.
  3. Resources / time required for each issue.

Obviously, we are not getting into the above business. I wonder if there is a simplification to the above which will make sense to the data that Mantis is dealing with.



2008-01-30 11:02

reporter   ~0016888

Actually, I was thinking of something fairly generic (and rough) such as the following:

Given a quick two week spike, for example, with two or three developers, let's assume there are ten tasks to get done.

If at the end of one week, five tasks are done, we are on schedule. Otherwise, not.

So basically we are directly correlating percent complete to percent of time passed.

This works for the two types of projects we run:

  1. Maintenance and refactoring phase. Lots of small atomic tasks that need to be tracked. Generally less than one day per task.
  2. Development phase. Team defines features/fixes, and then each developer responsible for a feature/fix will break it down into component tasks. No more than three days per task.

In this way we can roughly calculate progress against an intended deadline. Now, while I would never use this as an indicator to say "yes, we will definitely hit such-and-such a deadline", I would use it to alert me projects in trouble, or projects where we're way ahead of the game (indicating that resources may soon become available). This would be a useful dashboard feature when you have a lot of projects going at once.

All of that said, I do realize that many people may not use Mantis in the manner described above.. in which case it may be better to shelve this idea.



2008-01-30 14:15

manager   ~0016890

As you can see the way you track your project is tightly coupled with the way your team work. Hence, my vision for this is that the way progress is tracked should be part of a software development methodology pack that is can be a plugin on top of Mantis. For example, if your team is using Scrum, then you will need some extra custom fields for the issues, you will also need to the following reports:

  1. Product Back log
  2. Sprint Back log
  3. Burn down chart.
  4. Burn up chart.
  5. Ability to define sprints
  6. Ability to associate tasks with sprints
  7. Ability to associate an issue with the product back log (or base it on a status).




2008-02-06 00:58

reporter   ~0016962

Yeah, would be great if plugins were available for any of a variety of project management methodologies. I just need something (Joel On Software-esque) simple, but would find it illuminating to plugin a Scrum-type project management module, etc.



2015-04-20 16:00

reporter   ~0050568

Is this implemented for v1.3?



2017-01-24 11:40

reporter   ~0055296

And also, regarding the modern-ui of the v2.0.0, 100% should not be stripped (progress-striped generally means 'in progress')

Issue History

Date Modified Username Field Change
2008-01-23 13:12 Borszczuk New Issue
2008-01-25 12:57 Borszczuk File Added: colors.patch
2008-01-25 13:00 Borszczuk File Added: colors-2.patch
2008-01-27 15:33 vboctor Note Added: 0016849
2008-01-27 15:33 vboctor Summary Roadman "gauges" shall be drawin using different colors depending on the progress value => Roadmap "gauges" shall be drawin using different colors depending on the progress value
2008-01-27 15:33 vboctor Description Updated
2008-01-27 15:33 vboctor File Deleted: colors.patch
2008-01-28 12:51 nurikabe Note Added: 0016862
2008-01-30 03:26 vboctor Note Added: 0016882
2008-01-30 11:02 nurikabe Note Added: 0016888
2008-01-30 14:15 vboctor Note Added: 0016890
2008-02-06 00:58 nurikabe Note Added: 0016962
2014-11-25 11:04 vboctor Category graphs => reports
2015-04-20 16:00 atnz Note Added: 0050568
2017-01-24 11:40 Bozz Note Added: 0055296