Earlier, I referred to the term 'Checkin Experience' - I would like to expand on that a bit to make sure everyone is aware of what it is.
The 'Checkin Experience' consists of:
Selecting which files to include: This allows you to select all or a subset of files to include in a checkin (changeset).
Selecting which work items to associate with a checkin: This allows you to associate a work item with a checkin; once associated, you can view changeset details to see which work items were associated with a particular checkin.
Select which work items to resolve/close: This allows you to select which work items should be moved to the “next“ state. For example, if a work item is in an active state, selecting it would move it to a resolved state; similarly, if a work item is in a resolved state, choosing it would close it. [Note that the example transitions are samples only - work items are configurable, so they transition based on current state and the checkin action against it].
Filling in required and optional checkin notes: By now, hopefully everyone has the concept of a portfolio project; for each portfolio project, checkin notes can be configured. These checkin notes can be either optional or required for a checkin. Some sample of checkin notes would be: “Build instructions“, “Code reviewer“, “Documentation Changes“, ... One of the many uses of release notes is to query all release notes prior to shipping a product (more specifically new releases/patches); the readme.txt or other documentation can then be created from these notes.
Ensure Checkin Policies are met: These are great! There is an API to write policies against. All the policies that have been created will then be run prior to a checkin. This allows groups to ensure standards across a development team. There are many possibilities for policies including:
Next posting I will go into policies much more...