locked
Default Work Item Association RRS feed

  • Question

  • Before I begin...

    While working on several projects using TFS 2005 from early beta phases to 2008 RTM, we've discovered several missing features reducing the acceptance of TFS in software development teams. This forum is a great opportunity to share our findings with the Microsoft Team (doing a great job BTW) and other highly experienced users. Hence, I want to list and discuss our issues in this and future threads.

     

    First Issue...

    It should be possible to provide a default value (in the process template) for the check-in action column when associating work items with a changeset in the check-in pending changes dialog. The usability would rise significantly. E.g. when a developer checks-in a change, which only solves part of a task or requirement, which is normally the case, he only wants to "Associate" the work item and not "Resolve". By providing "Associate" as the default value in the drop down box, this would be easier. Because only in case, the developer wants to resolve a work item, he will set this value intentionally.

     

    One solution would be to specify a Default-Attribute in the Action-Element. Default="true" means top of the list or default. "Associate" should be set as default, if no other action in the work item specification is marked as default.

    <ACTIONS>

          <ACTION value="Microsoft.VSTS.Actions.Checkin" Default="true"/>

    </ACTIONS>

    Tuesday, December 4, 2007 10:44 AM

All replies

  • I second this.  More often than not I am only associating a check-in with a work item, not resolving it.
    Wednesday, December 5, 2007 3:14 PM
  • This is the exact reason we have removed the ACTION element from our process model, we simply have had too many wrongly "Resolved" items.

     

    Thursday, December 6, 2007 6:00 AM
  • Thanks for the feedback.  This is something I've heard about anecdotally from internal teams at Microsoft, but I hadn't heard it much from external customers before now.  I'm going to go see if there's anything we can do in Rosario to make it better.

     

    Thanks,

    -Doug

    Friday, December 14, 2007 3:04 PM
  • I will certainly add another vote for this feature.  We also removed the "Action" due to many work items being wrongly Resolved.  The way we use tasks it generally requires multiple check-ins before the task is resolved.

     

    Sunday, December 16, 2007 3:52 PM
  •  

    I think it should even go beyond this.  Other products offer user default templates. Perhaps default templates based on a project or product I am working on.  Those could be beneficial.

     

     

    Wednesday, January 16, 2008 2:28 PM
  •  

    We've had trouble with people accidentally "resolving" works items too.  We would much rather the default be "associate" - it would solve a lot of snags.
    Friday, February 22, 2008 9:40 PM
  • I will add my vote to the mix as well to request that at least by default, Associate (or another choice) should be optional.

     

    I would like, however, to put forth that from a review, and merging, and management standpoint - I have found it difficult if the developers associate too many changesets (especially to the same files) to a single work item. It makes it hard to understand what the ultimate change was to address the work item.

     

    I think this is more of a process/training issue than a technology issue - in that the developers may be checking in code before it is actually complete or tested - but I would be curious what others have experienced/think.

     

    The only technology solution I can imagine at this point would be to offer a "Compare to other changeset" option when looking at all the changesets linked to a work item - so if a developer changes file X 5 times on way to resolving the work item - I could then compare each changeset to another within the work item. I am not sure how this could be easily enabled in a UI experience - which is why I think this primarily goes back to a process/training issue.

     

     

     

    Friday, March 28, 2008 7:35 PM