It's all about the answers!

Ask a question

The release label creation at the RTC project area level

Mohanraj Ragupathi (54418) | asked Nov 05 '14, 1:52 a.m.
 I have the following team structure under project area
Proj-Cheeta-PF   ===>     Team1

When I tried to create the "Release" lable at project area level (used it in "defect" work item), there is an option to "restrict" visibility to other team members.
How this release label is “restricted” to the particular team area? Here how the tool identify which “Team area” this label should be restricted? There is no option to select the “team area” that should be visible or restricted! Based on which information this is “restricted”? Please clarify.

2 answers

permanent link
Ralph Schoon (62.3k33643) | answered Nov 05 '14, 6:38 a.m.

looking at the help, I have to admit, it leaves a lot to be desired in explaining this feature.
The best hint i found is when creating a release from a build in Eclipse:

What this setting does, as far as I can tell is as follows:

It hides the release as selectable in the Found In work item attribute for anyone who is not a member of the project area or a team area within that project area.

If you change the visibility in the Eclipse client, it also says "Project Internal".

The reason why this is not on an individual team level is basically because releases have no direct relationship to a team area. They don't even necessarily have a relationship to a build. So there is no ownership that could be used.

This feature is meant to allow the project to create many releases on the way to their final one, but hide intermediate releases from external users, so that they can't file work items against it.

Mohanraj Ragupathi commented Nov 06 '14, 6:01 a.m.

 Ralph, Thanks for the clarification. I have 2 concerns.

1. The "option" - Release is available to project TEAMS only - making confusion.
2. Based on the above comment (teams only), we assume and expect that if we select this option, that would be visible only to the team members. 

Because of more "teams" under one RTC project area and each team have multiple releases, over the period of time, the list is growing like anything. Users in the respective team find difficulty to select the appropriate one. How to address this?

Ralph Schoon commented Nov 06 '14, 6:25 a.m. | edited Nov 06 '14, 6:28 a.m.

To 1: I don't understand the statement. Releases are available to all teams in one project area. The releases Tab is only available on the project level. I can't see any relationship to a single team. Often one product is also created by various teams (e.g. DB, UI, Common).

To 2: I can't follow this and I have also experienced that what I expect a tool should do and what it really does is not necessarily a good match. I finally figured I have to follow how the tools are designed and potentially find ways to do what I desire based on what is available.

In RTC development, the releases tab mostly contains logical releases and also milestones e.g. 4.0, M1,.....  That keeps the list manageable.

To track work towards a specific milestone, track build work items are used. These are associated to build results.

It would be possible to use an attribute of type work item and a special work item type that specifies a release.

I agree there is room for improvement. Please file an enhancement request if you think this should be improved.

Mohanraj Ragupathi commented Nov 06 '14, 7:03 a.m. | edited Nov 06 '14, 7:06 a.m.

In our organization, we decided to have Platform(PF) as RTC project area and PF development,and application development (to support different customer)are becoming a individual team area. For e.g. Under one RTC project area (PF) we may different customer project like Ford, Hyndai, Honda, Nissan, etc... Because all those program are using that Platform and have different milestone. If we have 5 milestone and for 20 team area, it is totally 100 releases. In that case if we allow all the team members to see all the releases with in that project area, it is difficult. That is my concern.

Ralph Schoon commented Nov 06 '14, 7:09 a.m.

I agree with your assessment. However, the tool is, as far as I know, working as described above. Maybe using a special work item type would make this easier. The problem will probably be to come up with a value provider that selects the work items a user should see.

permanent link
Ritchie Schacher - IBM (47611) | answered Nov 06 '14, 11:54 a.m.
One option you can consider now (assuming any enhancement would take some time to make its way into the product):  For each release, prefix the label with a name that makes it easier to scope.  E.g., in your example:

[Ford] S1
[Ford] S2
[Honda S1]

At least, while the list will still be long, the user can scroll quickly to the release they care about.

The other thing you can do is make eager use of the ability to "archive" a release as soon as it is no longer relevant for current work.

Also, just wanted to make the usage is what you intend:  This is the value that will appear in the "found in" field, e.g, for reporting defects.  This is not the same as what is available for the "planned for" field.

Your answer

Register or to post your answer.