Yesterday, I introduced the task delegation process as one of the process patterns I found particularly interesting. It turns out that I am not the only one, and a Dogfood team has been formed around it, with Robert (Vice President of Business Development) and Madhav (Sales Engineer). For them to be successful, they’ll need some more detailed requirements, which I am happy to provide today.
The scenario is pretty simple: a task is assigned by one user (Task Owner) to one or more users (Task Delegates). When the task is assigned by the Owner, each Delegate receives notification about it, and is presented with two options, Completed or Deny. The task is considered completed once all Delegates have either completed or denied it. When more than one Delegates are presented with the task, the participation of every Delegates is expected, which means that the work supposed to be performed by a Delegate who would deny the task will have to be performed by someone else. Should a task be denied by a Delegate in such a fashion, it would then be the responsibility of the Task Owner to assign a new task to someone else.
In a first implementation, the task delegation process should provide a …
Yesterday, I introduced the task delegation process as one of the process patterns I found particularly interesting. It turns out that I am not the only one, and a Dogfood team has been formed around it, with Robert (Vice President of Business Development) and Madhav (Sales Engineer). For them to be successful, they’ll need some more detailed requirements, which I am happy to provide today.
The scenario is pretty simple: a task is assigned by one user (Task Owner) to one or more users (Task Delegates). When the task is assigned by the Owner, each Delegate receives notification about it, and is presented with two options, Completed or Deny. The task is considered completed once all Delegates have either completed or denied it. When more than one Delegates are presented with the task, the participation of every Delegates is expected, which means that the work supposed to be performed by a Delegate who would deny the task will have to be performed by someone else. Should a task be denied by a Delegate in such a fashion, it would then be the responsibility of the Task Owner to assign a new task to someone else.
In a first implementation, the task delegation process should provide a REST interface for creating, completing, and denying tasks. It should also provide an email interface (SMTP) for creating tasks (as described in the original article), and another email interface for completing or denying tasks. Also, the process should limit the number of Task Delegates to a fairly low figure (5 or 10), in order to prevent its use for spamming purposes, especially if it is to be deployed on the public Internet and offered for registration-free usage, as originally suggested.
The interfaces for task creation (both REST and SMTP) should support the setting of a due date for the task. By default, the process should send daily reminders to Delegates until they either complete or deny the task.
Finally, the entire process should be implemented in such a way that SMTP interfaces (both inbound and outbound) are bound to the REST interfaces, making it easier to add new ones over time. Examples of such interfaces could be a plug-in for Microsoft Outlook, an extension to Singleshot (which was recently released under AGPL v3.0), or an integration with Salesforce.com.
Here we are. Good luck to Robert and Madhav for this really cool project!