When I'm viewing a project and click the task tab I like the ability to order the tasks by assigning them a number.
I've recently run into an issue with the ordering. Here are some steps to repeat...
- in a project, select task tab
- create 10 tasks on a project
- Number them 1-10
- Assign 2 sub-tasks to 10
- number them a and b.
You'll notice that the tasks become ordered as 1, 10, --a, --b, 9, 8, 7, 6, 5, 4, 3, 2.
I tried to get around this by assigning the tasks all 2 digit numbers. (01, 02, 03) but this did not affect the ordering as I expected it would.
It would be nice if the sorting logic could handle 10 or at least that it knew what to do when I reassigned 01, 02. Also, it's odd to me that it went 1, 10 and then reverse numerical order.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | stormtaskorder.patch | 821 bytes | pvanhorn |
Comments
Comment #1
pvanhorn commentedI have been using the Weight field for ordering. The Step No field is just a text field, so it won't sort with things like 10, 1b, or 100. Attached is a small patch to move the Weight field around on the form to make it more visible and to expand the choices to 100.
Comment #2
Roberto Gerola commentedI added visual ordering and nesting in the latest dev version, like in menu interface.
I'll consider also this patch in any case. Many thanks.
Roberto
Comment #3
Roberto Gerola commentedMixing letters and numbers in step number field isn't a good idea in my opinion.
This field has been studied to follow this standard :
WBS coding scheme
It is common for Work Breakdown Structure (WBS) elements to be numbered sequentially to reveal the hierarchical structure. For example 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point. A coding scheme also helps WBS elements to be recognized in any written context.
http://en.wikipedia.org/wiki/Work_breakdown_structure
Comment #4
flickerfly commentedThat's something that could be documented a bit or enforced by the module through a validation of the field perhaps?
I'm going to return this to a bug report with the idea that the bug is the lack of proper validation so the code is receiving the expected values. Otherwise, you end up with the results I received because you had improper input.
Does that make sense? I don't mean to be a pain, but wish I'd have been told this somehow before I started building projects in STORM.
Comment #5
dbt102 commentedSorry fickerfly, but Roberto is right about this.
The princples of constructing Work Breakdown Structures have been very well defined for many years (like the late 1960's). They developed from PERTs - Program (or Project) Evaluation and Review Technique -charts used in the 1950's. PERTs did use letters to identify activities.
Storm is a great module and I really appreciate the fast pace that its been developed. I especially appreciate the fact that it is following the standards for WBS. This way it can be applied to many disciplines beyond that of manging a project to build a website. In my case I think its great for facility managment purposes, like building new buildings (or renovations to buildings).
At this point I build out my WBS in Storm once I've already mapped it out using a spreadsheet. On the spreadseet I identify project milestones which tend to be recurring events that can occur for one or more tasks/activities. I use letters like a,b,c... to identify milestones so they stand out from the task numbers. I always show them in the 'time bar' of the Gant Chart I create next to the WBS tasks on the spreadsheet. My typical milestones are things like 'submit meeting minutes', 'submit documents', 'special event', etc. Since my milestones are distributed randomly throughout the project I don't event try to enter them into Storm, other than a note to the Storm project/task and then only to record misc discussions (such as phone calls).
So for me, mixing letters into the task numbers would not be a good thing, quite confusing... For government construction projects they could even cause the WBS to get rejected if they were used to identify tasks (or subtasks).
Comment #6
flickerfly commented@dbt102: I think you misunderstood my last comment.
I'm simply asking for validation on the field as that would provide clarity to the intended standard being used.
Their is no place I've seen that tells me this should be used this way. Some validation would at least tell me that putting letters in breaks the order.
Comment #7
Roberto Gerola commentedOk, adding a validation is a good idea I think.
Roberto
Comment #8
flickerfly commentedCool, Thanks. :-)
Comment #9
Magnity commentedMy take on this is that: the weight's system and menu style handles are used to reorder the tasks and to control parentage and that bit is fine.
The step number should not be validated as it is up to the owner of the system to say whether they wish to use the WBS or other. The step number does not control task order.
The only reason for change is I think would be if the step number was in fact a calculated field from the orders, so that as you moved the tasks around the step number would automatically change.
Comment #10
flickerfly commented@Magnity, thank you for your work to clean up the issue queue around this project. I know it is helpful to me whan determining the direction and thoughts that have already been expressed around this project. In this case, I believe you jumped the gun a bit. If the project maintainer, Roberto Gerola, has agreed that it should be fixed and is a good idea, then I don't think this should be marked "won't fix". Please don't allow me to discourage you from further bug triage work.
Comment #11
Magnity commented@flickerfly, I'm quite happy to review a patch that improves this area of the module, but its not an area that I think needs fixing, and not something that I am going to fix myself - therefore don't think I jumped the gun by marking this as 'won't fix'.
I think a reasonable compromise would be that I will mark this as postponed for now to give a chance for comment by anyone else and even the potential for a patch to be submitted.
The sort of patch that i'd be interested in would be if the WBS was automatically calculated based on the task order, or if there was an option to validate / or not depending an admin setting.
Comment #12
flickerfly commentedI see you've been added as a project maintainer. I hadn't caught up with that when you posted this. That clearly makes your position a lot more weighty. I support the "feature request" change.