What improvements to subscriptions and notifications would you like to see?

 

I'm posting this on behalf of Matthew Moloney -- a PM intern who has joined us from Australia! 

He's got a query on what sort of improvements you'd like to see in the subscriptions & notifications space in a future release.

------

G'day everyone,

I'm looking for feedback on a design for a subscription and notification interface that will allow users to specify which events they would like to be notified on. I would also like to get a few ideas on what would be the most common types of notifications that a users such as you would like to subscribe to.

Some ideas have been:

·         "I would like to receive an email when any of my Bugs have been updated"

·         "I would like to know when I have been assigned a new work item"

·          "I would like to be notified when a work item that was previously assigned to me has been assigned to someone else"

 

By collating such request into a set of common requests we can try to optimize a user interface.

The idea is analogous to the Outlook rules and alerts wizard. The intent is to have two different approaches. A wizard that will be able to facilitate the event subscriptions for 80% the most common cases, and a Query Builder driven approach that will handle the remaining 20%.

The most important input I am looking for is your answer to the following question; if an ideal subscription and notification infrastructure existed what events would you subscribe to and how would you like to receive those events? In order to quantify each of the answers please give an indication on the subscriptions importance (integral, very important, nice to have) and on the frequency of occurrence (all the time, regularly, occasionally).

Some things to consider:

If you could only subscribe to changes in queries as opposed to individual work items could that be enough?

For subscribing to a change in a query how would we define 'a change in the query'? 

·         When work items within the query has changed in a certain way; or

·         A new work item enters the query results or an old item leaves the query results

 

And, what kinds of notification endpoints are desired?

·         Email

·         Instant Messaging

·         RSS

·         Newspaper (A webpage collating events)

Thanks for your time,

Matthew Moloney

Comments

• Anonymous
  January 30, 2008
  For TFS05 and 08 I wrote a custom Notification server that monitors changes in Work Items. I had to do this because the main feature I need is the ability to make sure that EVERYONE who uses TFS gets certain notifications.  This is also helpful because it means they'll get notifications for a new TFS project without them having to add their own subscriptions. Currently the following subscriptions are sent to everyone:

• Email when the assigned to field changes to or from me (integral)
• Email when a task I created that is assigned to someone else is closed (nice to have) I'd also love if there was a way to "subscribe" to a work item and be notified of all changes made to it. (important) -- For my needs 'change in a query' would have to be defined as: "When work items within the query has changed in a certain way" The only way I need to be notified is via Email.

• Anonymous
  February 01, 2008
  Let me start with the simple question; Endpoints. Do I have to choose? I'd love to see both RSS, E-mail and IM. I don't see a great need for "newspaper", but a simple XSLT combined with the RSS feed would solve that anyways, so no biggie... I would say that the priority list would be like this:

1. IM
2. RSS
3. E-mail
4. Anything else... As for the sorts of notifications;

• Notification when I'm assigned a new wi (integral, all the time)
• Notification when one of my registered Wis are updated (nice to have, regularly - weekly)
• Notification when one of my registered Wis are closed/reopened (status change) (very important, all the time) Changes in queries should be the way to go, make them atmoic enough and it fixes all the issues.

• Anonymous
  February 01, 2008
  As for endpoints - my priority list would be

1. Email
2. IM
3. RSS That said while I never did this my understanding was that you could hook in to the eventing system and have callbacks so that you could write a program that was callback to automatically take action versus simply notification.  I would hope/expect that capability to remain. From the query perspective I suppose that in essence notifying off of a query is what happened in TFS 2005 we just used a different language (VSEFL I believe) to express the query.   From a WorkItemChangedEvent perspective there are the scenarios for a developer for example where he really only cares about his items and changes to his item.  Changes to status, iteration, estimates, description, links, etc...  Additionally there is the scenario for a PM where he or she would want to know about changes to all work items.  The Work Item Changed Event scenarios are a must have. There are a bunch of other events/notifications from TFS2005 surrounding builds and version control events which are also pretty critical - build status changes, source file check-ins, perhaps merges and/or branches that meet a certain criteria (branching or merging from/into certain branches). A nice to have would be eventing/notification surrounding reporting or off the warehouse.  Today we have reports that provide us information, but they aren't inherently actionable.  Someone has to go look at them and in many cases that works.  I can imagine scenarios where I might want to take data points and fire events based on certain criteria.  One that comes to mind is if my test runs results fall below a certain percentage I might want that to notify me to take notice or perhaps to even hook in and have it automatically create work items to cause some action to be taken.

• Anonymous
  February 02, 2008
  Thank you for your comments! Excellent feedback! -Siddharth

• Anonymous
  February 07, 2008

• Decision maker dashboard (WPF) :)