dwayner wrote:

Our current source code control tool is tightly coupled with the
defect/change management and build. I would like to know if what we
presently do can be accomplished within RTC.

Today:
1. Create a Defect/Work Item - state is open(new)
2. Begin working on Defect/Work Item - changes state to working(in
progress)
3. Completed the code change and deliver the changed code to the
repository - This changes the state of the Defect/Work Item to
integrate(resolved)
4. We then prepare for a build, by associating defects/work items with
the build we are about to do. We execute the build and if successful,
the state of all work items associated with the build is changed to
verify

The benefit of this tight coupling is that one can easily query say
all work items in "New" state and know that they haven't
been address yet or
query all work items in verify state and know that the associated
changes have been built.

Is this possible in RTC?

It's mostly possible, depending on how automatic you need the process to
be. In RTC, the work item state changes are all manual. When you start
working on a work item, the owner needs to manually change the state to
In Progress; RTC won't change the state when you start checking in
files. When changes are delivered to a stream, the owner needs to
manually change the state to Resolved (or whichever name you want to
pick for that state). (Though RTC provides a convenient Deliver and
Resolve Work Item command so both the delivery and the state change can
be done in one step.)

The one thing that is really missing is automatically changing the state
of the work item when its change sets have been included in a successful
build. RTC will record the first build that contains the work item's
change sets (under Included in Builds in the Links section of the work
item), but that's not necessarily a successful build.

It is possible to create a work item query that selects work items based
on whether or not they have an Included in Builds link. Even though it
is not a state change, would that be enough automation for you?

Others have requested the same thing as you: an automatic state change
when a work item's change sets are included in a successful build. I'm
sure there is a work item open against RTC to do that. But I see a
couple problems with the feature. Some work items are delivered to
multiple streams and are included in multiple builds. But it is usually
only one build in particular that you want to trigger the state
transition, not any random build. Some work items have several sets of
deliveries (such as if the first delivery didn't behave as expected), so
the work item will show up in the same build several times. But
repeating the same state transition several times may be problematic.
Neither of these issues are show stoppers; I'm just trying to point out
that it's not a simple feature.

Hi

As the members are shared across the teams and projects, is it possible to query to find details of all members of a particular team/project area

(1) The member's availability in terms of scheduled leaves
(2) %allocation made available for the project

Today the only option is to open each user profile and then see the percentage marked and then check the leave's planned


This will help a lot in allocating the work initially.

Thx & Regards
Jagadish

Any update on automatic state transitions now that 3.0 is out? My product as requirements very similar to those mentioned by Dwayne.

dwayner wrote:

Our current source code control tool is tightly coupled with the
defect/change management and build. I would like to know if what we
presently do can be accomplished within RTC.

Today:
1. Create a Defect/Work Item - state is open(new)
2. Begin working on Defect/Work Item - changes state to working(in
progress)
3. Completed the code change and deliver the changed code to the
repository - This changes the state of the Defect/Work Item to
integrate(resolved)
4. We then prepare for a build, by associating defects/work items with
the build we are about to do. We execute the build and if successful,
the state of all work items associated with the build is changed to
verify

The benefit of this tight coupling is that one can easily query say
all work items in "New" state and know that they haven't
been address yet or
query all work items in verify state and know that the associated
changes have been built.

Is this possible in RTC?

It's mostly possible, depending on how automatic you need the process to
be. In RTC, the work item state changes are all manual. When you start
working on a work item, the owner needs to manually change the state to
In Progress; RTC won't change the state when you start checking in
files. When changes are delivered to a stream, the owner needs to
manually change the state to Resolved (or whichever name you want to
pick for that state). (Though RTC provides a convenient Deliver and
Resolve Work Item command so both the delivery and the state change can
be done in one step.)

The one thing that is really missing is automatically changing the state
of the work item when its change sets have been included in a successful
build. RTC will record the first build that contains the work item's
change sets (under Included in Builds in the Links section of the work
item), but that's not necessarily a successful build.

It is possible to create a work item query that selects work items based
on whether or not they have an Included in Builds link. Even though it
is not a state change, would that be enough automation for you?

Others have requested the same thing as you: an automatic state change
when a work item's change sets are included in a successful build. I'm
sure there is a work item open against RTC to do that. But I see a
couple problems with the feature. Some work items are delivered to
multiple streams and are included in multiple builds. But it is usually
only one build in particular that you want to trigger the state
transition, not any random build. Some work items have several sets of
deliveries (such as if the first delivery didn't behave as expected), so
the work item will show up in the same build several times. But
repeating the same state transition several times may be problematic.
Neither of these issues are show stoppers; I'm just trying to point out
that it's not a simple feature.

Another year has passed.  RTC 4.0 is out. 

Are there any updates?

It would be great if, on completion of a successful build, the work items delivered by the build could automatically be updated with the Build Id in which the work item was first delivered.  This automatic update should only happen if the developer has pushed the state of the work item to "Implemented".  I.E., if the developer is not finished, the work item should not be automatically updated just because the developer has checked in some initial modifications.

this is not available out of the box from IBM

one could create an extension to provide this function, or use an integrators tool using OSLC to provide these actions.  TaskTop,Kovair and others provide this kind of functionality