Default Filed Against (Category) field for work items created within a plan
I've read that the default Category for work items created in a plan doesn't use the defaults created for the project (described here https://jazz.net/forum/questions/42540/how-to-default-quotfiled-againstquot-field-for-work-item). I can't seem to figure out how Jazz determines the category for work items created from within a plan, and how one can control this. For example, when we're in a plan and create a new one for a developer, it sets up some of the fields by default properly (like iteration and owner), but the category. This is close... https://jazz.net/forum/questions/66430/filed-against-should-default-to-unknown-for-new-work-items And states that the category is coming from the project configuration somewhere? I have no teams setup...
showing 5 of 6
show 1 more comments
|
Accepted answer
Ralph Schoon (62.3k●3●36●43)
| answered Jun 23 '16, 4:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jun 23 '16, 4:39 a.m.
Look at: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=303341
The category is assigned depending on the plan owner. The algorithm picks the category which is: Ralph Schoon selected this answer as the correct answer
Comments Also see: https://jazz.net/forum/questions/223900/can-we-control-the-default-filed-against-category-field-for-the-work-item-created-within-a-plan-view/224275 for a way to set a default in 6.0.x
|
3 other answers
Correct or not, I've found that the category is defaulted to the alphabetically first category available for the plan scope. I believe this covers both when you do and do not have team areas defined. I've also found a case where the default is something not within the scope (but that must be a bug).
|
Millard Ellingsworth (2.5k●1●24●31)
| answered Sep 24 '13, 11:25 a.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER
If you create a work item (not from a plan) there is a "Guess Category?" link (described briefly here -- look under Automatic Work Item Categorization). I imagine it is guessing for you when creating an item from a plan. At that point, the only data it has is the person you assigned it to and the summary. Depending on how much it can glean from the summary, the results may vary.
Another mention of the feature I found says "Since this feature uses the fulltext service to derive the category from similar work items, it works best if the description attribute is rich in content." Unfortunately, when adding from a plan, there is no description yet. I presume it is also using the summary field but I could be wrong.
Filed Against is often a required field and if "Unassigned" is not valid, some sort of guess is necessary or the new work item cannot be saved (which may cause the plan to not be saveable). While it is difficult to generalize across our user base, I think it is common for a team/project to be associated with a relatively small number of categories, perhaps even just one (which makes guessing correctly quite easy).
We could file a work item to improve the guessing but it could still end up wrong -- which means we do a bunch of work and nothing gets better. You could write a default value provider that could coerce the Category (though you are now always choosing the same one or the onus of guessing is shifted to you). I'll spin up a short experiment to see if I can think of something else.
Comments I created a scrum project area and setup 5 categories with no teams. I brought up the Sprint Plan and added some work items, trying to put certain words in the summary and assigning to certain categories, hoping to get the system to "learn" that if "Marco" was in the summary, it was likely to be in category Subsystem2 and if "Subsystem3" was in the summary, the category should be Subsystem3. Then I added more tasks using the clues. Every item I added defaulted to Subsystem1, the first category in the list (that wasn't Unassigned). In my example, "Unassigned" is the root category and all others are direct children.
I then added some similar text to the Description of all of the items assigned to Subsystem2 in hopes of seeing the suggested category change. Still always defaulted to Subsystem1. At least for my simple case, I'm not seeing any interesting behavior at all.
|
Hi all,
Any progress on this issue? I have encountered the same situation on a project. The category (filed/against) information is determined by the category association when creating a workitem under the plan view. If no association is assigned, I think the first line in the category list will be selected. |
Comments
Hi, Patrick. Can you provide some more details? What version of RTC? Are you using the Eclipse or Web Client? It sounds like you have multiple categories but no team areas. Do you have more than one timeline? Are you wanting to understand or coerce the behavior?
RTC 4.0.3. I know this happens on the web client, haven't tried it on the eclipse one. I do have multiple categories and no team areas. Only one timeline. I'm wanting more of an understanding and a recommendation on how to use RTC based on the way we work...we want to categorize things based on the subsystem, but everyone on our team is concerned about it. On any given iteration, we can work on multiple subsystems, so there's no distinct timeline. Each release may or may not release the deployable artifacts of each subsystem, but they are all done together in one big shot (allowing for sharing of documentation like release notes). Categories is what I thought would be best for this to help with searching, but maybe what I really want to use is tags, and remove the category field all together, because we're not using the separate teams/timelines?...hmmm...opinion?
I generally recommend at least 1 team area (for the reasons outlined here).
Your example is exactly what I'm talking about (it's "this"). I don't understand what RTC is using to determine the default the category when creating a WI from a plan in the work breakdown view by clicking the create item button beside a user when there are no Team Areas.
This link doesn't really say "why" we need to make a Team Area...the section"Create and associate a work item category with the team area" states it merits a whole other article - is there such an article? In any case, if I make a Team Area and do this association, that'll probably do it, Non?
The main "why" is separating the workers from the watchers. If you have stakeholders, you may have noticed that they appear in your plans even though they will never get assigned work. Changing this later in the project if you suddenly start taking on stakeholders is non-trivial. No, I don't think creating a team area will just fix your concerns (see answer below).