Back to issue list Export

A bug tracker contains much of the data necessary to make a decent piece of project management software. The key requirements are: o Issue dependencies o Time estimates o Progress estimates o Developer Availability o Gantt charts and other useful PM reporting It may not be the case that Nitpick is the right software to put this project management feature set into. It should certainly be optional and ignorable, perhaps even disabled by default. The theory would be that there would be a single developer friendly place to view what should be done next and when it should be done. It would also provide an easier place for the PM to view the most up to date completion estimates (even if only quite coarse via issue completion) and to have a permanent and easy to find location of discussion/descriptions of features and requirements. This would need to tie in with the feature described in 4ebf2a29 to be useful in all cases. First in the fact that issues over multiple repositories would have to be queried to produce the reports. More interestingly is handling feature completion within branches. It isn't reasonable to ask the PM to reconcile completion estimates from all the branches by themselves, but they would also likely desire to have their information updated more frequently than when a feature is complete.

travisb 2012-07-19 11:02:40
hash: 1f836fe168c00926d9fef6ec11501f6199ddc98ba4ee264142a4b7a4e1b1ec80
Date: 2012-07-19 11:02:40
User: travisb

This also needs the functionality from 73f8e6dd

travisb 2012-11-01 21:39:57
hash: 44075e674d70d14855719836de9db2d90f30bad61f97c18e360df2b3db82c0e2
Date: 2012-11-01 21:39:57
User: travisb

One critical feature is some way to produce a project Gantt chart for a project overview. The use of this is to give a PM or interested developer a view of the critical path as currently assigned and some idea of how feasible the current schedule is. It would also be useful in determining what work is getting done.

travisb 2012-11-01 22:19:40
hash: f877916c07319240765a903ae34636403ed4c27aeb2a756fe91b215f69c64a90
Date: 2012-11-01 22:19:40
User: travisb

To produce a Gantt chart any particular issue needs: - An owner - An estimated time of work - An estimated current completion - A started timestamp - A finished timestamp Every user also must have a number of hours per day (likely for any day of the week) they will be working on this project. Every Fix_By also requires a deadline so a critical path can be computed, though the system should attempt to find the minimum time option. Assuming that any single person will only ever work on a single issue at a time is reasonable.

travisb 2012-11-03 10:32:00
hash: 31abdd2c098706ff8cb802baa27c38277114e8327b1d5e8df4dd4fb72e06b671
Date: 2012-11-03 10:32:00
User: travisb

From the discussion here ( is seems that it could be useful to support non hour based time measurements. Specifically complexity based estimates. If we allow integer values for time estimation of a project (nominally hours) and further allow float values for the time a dev has available on any particular average day of the week then we can either have that scaleless number represent hours or complexity units. This would enable the Agile style Planning Poker.

travisb 2012-11-03 10:46:47
hash: 121cc13d58c9c97d33cac262cf445221b7d41cf7abb3d6b8ccd114d5f86ad3b7
Date: 2012-11-03 10:46:47
User: travisb

Every Fix_By also requires a deadline so a critical path can be computed, though the system should attempt to find the minimum time option. Assuming that any single person will only ever work on a single issue at a time is reasonable. Let's evaluate why we need each item: o Owner - Needed so we can schedule in parallel o Estimated time - Needed so we know how long any particular issue will take o Current completion - Needed to straddle an issue on the current date line for scheduling. If we don't have this then we must assume when we schedule that any issue is either not yet started or done. This causes problems with lengthy items and causes the schedule to jitter. Of course, if developers don't keep their estimated completion up to date the same happens, but that could happen at a fixed time for the team. o Started Timestamp - Needed to record when work was started in order to pin the work in realtime in the past. Probably only necessary if you want to show a Gantt chart in the past. o Completion Timestamp - Needed to record when work actually stopped. Probably only necessary if you want to show the Gantt in the past. o Units of work per dev per day of week - Necessary to convert the time estimate of an issue into a number of days of work. Must be in the same unit as the work estimate for the issue, but otherwise requires no fixed unit. o Fix_By requires a name and date. Milestones require a deadline in order so know scheduling priorities. Issues themselves could have deadlines instead, but that would lose the effect of automated scheduling. From the above it seems that start timestamp and end timestamp aren't actually necessary since I don't know of any particular use for Gantt charts of the past. Of course there will still be a record of who did which issue, but pass-offs would be a bit funny. If that level of accuracy is necessary then new issues should be created for sub-issues instead of changing the ownership of a task. Summary of necessary new information: - Estimated units of work for task - Estimated percent completion for task - Estimated units of work per dev per day of week - Fix_By date

travisb 2012-11-04 15:57:33
hash: b807253608080afa1907aee29751015462475d6679856cfe670ec251670eedac
Date: 2012-11-04 15:57:33
User: travisb

If we don't have anything indicating a start time, then we won't be able to handle external dependencies based on date without some ugly hacks. In fact I can't think of a workaround that will work at all.

travisb 2012-11-04 16:33:09
hash: 90d56d2975a816d0e6ae12adde018afc366fe0e877d20d7af955f52a30e505f7
Date: 2012-11-04 16:33:09
User: travisb

Unfortunately adding that information makes the entire setup NP-Complete. If I can work out an efficient algorithm for the simple case of only inside the dependency tree, then two modes could be provided. A most where none of the tasks have non-zero earliest possible start times (meaning they can't start immediately assuming all the dependencies where magically complete) and then a mode where there are these external earliest possible start times for some tasks.

travisb 2012-11-01 22:22:54
hash: 58dd6f6324f60396af3fac15062ab0fc1a3b8f010e4ea054b5b6ebd88526a33a
Date: 2012-11-01 22:22:54
User: travisb

Resource balancing should be done by a human, it's simply too much work to automatically enter skill equivalences. The UI for this would be to click on the issue in the Gantt chart and it would open the bug. The user could then change the owner of the issue and recompute the Gantt chart. Of course the critical path should be specially coloured.

travisb 2012-11-03 11:09:44
hash: 89844f06c533b660ba0cb423a0f69d2554aca2a57d26872742781f453901a3e7
Date: 2012-11-03 11:09:44
User: travisb

I don't think we should necessarily do a traditional Gantt chart. A traditional Gantt chart has the vertical axis be tasks and the horizontal axis be time. This is reasonable if any particular task requires multiple people or other resources to accomplish, but it makes it difficult to see where juggling people or equipment would shorten the schedule. Since Nitpick won't support automatic resource balancing manual balancing must be made easy. On most software projects there is only one scarce resource, developer time, so it should be possible to do a different chart. My current thought is to have developers as the primary vertical axis and time as the horizontal axis. Then you show issues as blocks within that graph. Since it is assumed that only one task may be performed at a time (as that's more efficient of developer time) this should work well. Dependencies between tasks will be shown with links. It may be necessary to have a secondary vertical axis (by having a developer take multiple lines) to help differentiate between issues the same developer does which have a dependency.

travisb 2012-11-03 19:39:08
hash: f1695376f06823ab5cc6b9ad08b5e1ce85fcd62eee88c728f0cecbc41901ad39
Date: 2012-11-03 19:39:08
User: travisb

An alternative is to have the secondary grouping on the vertical axis be each individual issue. So every developer would have a row for every future task they have to handle. This may make it difficult to see who has too much work and needs to be juggled.

travisb 2012-11-03 20:40:14
hash: a02bf5dbb6f11357b661aff58a1637c25b8c22b50f26c0b5a812ab5aab36ba56
Date: 2012-11-03 20:40:14
User: travisb

After drawing some samples I don't think having a secondary grouping per person is valuable. Better to have one column per person with one task after another. Tasks should be colour coded for the Fix_By they are due for. On mouseover of one item it'd be very useful to highlight every task in the subtree, that is, every task the selected task depends upon and every task which depends upon the selected task. I suppose that this isn't a Gantt chart at all, but seems that it would be more useful. It'd be similar to a complex project Gantt chart if it were filtered to a single milestone.

travisb 2012-11-03 20:51:32
hash: 2a788aaa98ba6b956c541646fb9e72bbcf1fd69fb579cbbd7dd53d2d96603c70
Date: 2012-11-03 20:51:32
User: travisb

One situation where multiple columns would be useful is when a developer has some tasks partially complete, but they've come upon a new dependency and had to stop. In that case the partially complete issue could have the work remaining start whenever the dependency is expected to be resolved with the completed portion above it, showing completion status. Since there would be two tasks listed for the same time period (some amount of work-to-be-done on its own in the developer row and the work-to-be-done of some other task overlapping the already completed work of the first issue.

travisb 2012-11-03 20:32:35
hash: 2ba8658e3f54aa9fe0e25f15f65bf73ffe892e3a10062a98561fa19feb4d577f
Date: 2012-11-03 20:32:35
User: travisb

One feature that would be useful is to have items which aren't completed coloured based upon their completion status. So the first x% would be green, the last 100-x% blue to signify that approximately x% has been completed. If the issues in the past are only those which haven't been completed completely yet then doing this should give a decent idea of which tasks are on schedule and which are behind.

travisb 2012-11-04 18:16:57
hash: 45f159be6db79e7f661272d5b92361e12cca26e5485baa4b94a5cf170bd14c07
Date: 2012-11-04 18:16:57
User: travisb

Furthermore, if the scheduling worked backwards from the deadline and showed the current date in some special way, then it would be easy to see how far various things are behind without complicating the scheduling algorithm with having to iterate juggling until the start fits where the current date is. Doing this jiggling has issues when it comes to weekend and the like, since some people may not be on a particular project seven days a week for an even number of work units a day.

travisb 2012-11-01 21:44:53
hash: 36cc89382cb61edc74f5e38502b952ff6824a548e240204691b96d5dd22a6733
Date: 2012-11-01 21:44:53
User: travisb

Another critical feature is a list of "What should I work on Next?". This would be a list of suggested issues for a developer to work on in the order that they should be done. This should take into account schedule needs, including scheduling between other developers, dependencies (ie. don't suggest an item with an unmet dependency) and arbitrary due dates (which could be Fix_by milestones).

travisb 2012-11-01 22:17:44
hash: e371c2eb4800c290e490e43b74b19dbff80f5177ad68c06cd84be751c0539d9f
Date: 2012-11-01 22:17:44
User: travisb

This feature should also automatically produce reasonable schedule dates for any particular item. This would be useful when using Nitpick as a personal scheduler, perhaps as part of a larger project. The idea is that you fill in the scheduling information and then any particular issue would have a reasonable finish date computed.

travisb 2012-11-12 09:44:10
hash: ee2ac98afa64e690ec9242ae0bb3f2714f3709ece2f12de057dfcfaf582ecb3b
Date: 2012-11-12 09:44:10
User: travisb

Here is the current list of things left to do on this feature: 1. Take the difference in fix_by dates when computing the schedule 2. Show overlapping items when one is to be continued 3. Colour code the issues by their fix_by

travisb 2012-11-12 09:51:33
hash: 27fb2910c3ac2c8d02ce3bef09208aa7f3190648ec1de711a8ce058cb7fe3efc
Date: 2012-11-12 09:51:33
User: travisb

I forgot all about: 4. Document this all 5. Colour code the critical path a different colour by default.

travisb 2012-11-12 10:33:58
hash: 8b270bef90a58b0c2022d95d629d74fa39e812f3b4560c5e0cb5442041324827
Date: 2012-11-12 10:33:58
User: travisb

After trying it, I don't believe that statically colouring the critical path is the right thing to do. It's non-trivial to mark the tasks on the critical path in such a way that a minimal set is marked and every time span is covered. abd97310fcb2 seems to cover the need of marking the critical path and does it in a more general and accurate way.

travisb 2012-11-12 12:22:58
hash: eb4792e267cbbc05c73eb151be67779915bef94181444c2572e1a97984c72b94
Date: 2012-11-12 12:22:58
User: travisb

Overlapping tasks to show the partial completion status is perhaps not worth it. - It's quite a bit of work to do this because HTML tables don't work in a useful manner for this. - It will greatly increase the horizontal space needed to show the schedule. This will make things less useful. I'm going to make this a new issue to consider later, a7fcc48d

travisb 2012-11-19 19:08:11
hash: f26388825df94e5ca705b47a1d0d9f570da91746465fc5c1fbd28c6412484834
Date: 2012-11-19 19:08:11
User: travisb

Similar to the situation in 73f8e6dd adding the scheduling feature required new metadata. New issues will have it, but old issues won't. To add it create a helper script #!/bin/bash awk '/--/ {print "Units_of_Work: 1000\nPercent_Complete: 0";} {print}' $1 > $1.tmp mv $1.tmp $1 And then run it with: find .nitpick -name issue -exec /path/to/ \{\} \; This will modify all the existing issues to have the default values of the new metadata items.

Tracked by Nitpick