AWOB Task 007

MPDL,GAVO

General Information
Grouping: Task management Short description: Define model and use cases for AWOB task management

Use cases

 * Create Task
 * Edit Task Metadata
 * Change Task Status - Start, Close, Cancel Task
 * Change Task Visibility
 * Manage Task Members

Conceptual Model

 * AWOB Conceptual model HTML documentation

Use Scenarios

 * Task Use Scenarios
 * Task Use Scenarios - discussions for the scenarios

GUI Layout

 * Task Management Layout
 * Task Management Axure prototype

--Rupert 09:58, 8 February 2013 (CET) This Prototype is outdated --Jkim 13:43, 11 February 2013 (CET)Could you please replace it with the latest version? Thanks.

Implementation on awob0.5

 * AWOB_Task_019

Early thoughts
In AWOB email "[AWOB-111] Re: [AWOB] 01 Startpage LogIn: Comment added to AWOBDashboard". June 9 2011:

... I think being project centered is important for what makes AWOB special.

In this context it would further be nice to put special emphasis on tasks assigned to the user, a TODO list. This can be of great benefit to tracking the provenance of scientific results. This is the nice aspect of the Project view in Roderik's version. The little window in the middle, "Workflow Tasks assigned" needs consequently more attention.

It is interesting that individual scientists that Jai Won has talked to here all come up with this idea of tasks, or find it useful when they hear about it. It allows for a nice parallel to work flow engines, complete with input/output "ports" for individual tasks. A task is assigned to one or more project members, often with the express goal to reduce/analyse one or more input data sets, and leading to one or more result data sets. This can be as "simple" as the task of creating a nice plot from a table or image to be used in a paper, running source extraction on an image to produce a source list, or to a complex calibration of raw data to produce a clean scientific result.

Even if the description of *how* the task is performed may not need to be very formal, it does organise the work more explicitly.

It also seems the correct way to link results together. Remember this was one of the motivations for AWOB: a scientists sees a plot and would like to get access to the underlying data. We had not discussed how that relation is to be made/modeled, but the concept of a Task can play that role very nicely.

...

AWOB Conceptual Model
This UML model is used to define the main concepts for the AWOB system and their relationships. It comes in the form of an XMI file designed in the MagicDraw Community Edition 12.1 (old, no longer available). From this we can generate various representations using the VO-URP "framework" developed by Gerard Lemson and Laurent Bourges. In particular we have generated HTML documentation of the model(NB the mime-type is not set properly yet in SVN for the HTML file, hence some browsers do not display the HTML from the link using the apporpriate style sheets). An image of the model is https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/AWOB_Conceptual_Model.png

Task properties
Main task attributes (simple values, provided by users or automatically derived by a system) Jkim 10:56, 10 February 2012 (CET) It may need to store important dates in the future. But for now no one has asked and there is no need for milestones.
 * id - main task identifier
 * summary (goal) - short definition of the goal of the task or summary of the task description
 * date created - date when task was created in the system
 * date last updated - date when task was last updated in the system (update of any of main properties or addition/modification of the task component)
 * start date - date when a task shall start
 * due date - approx date when a task shall end
 * task status - a status of the task, proposed values(not started, in progress, on-hold (?), finalized, in-review(?), closed )
 * type (in some projects various types of tasks can be provided, the question is here if we really need to think of it or consider it as a "tag", see Related resources below)
 * milestone (?) --Natasa 11:44, 9 February 2012 (CET) - some projects may organize themselves in milestones

Task Components
Additional resources related to a task. These are usually complex types and are not attributes, rather are concept which can exist on its own as well, but is strongly related with a task (i.e. can be created as result of the task, as input for fullfilling the task, as additional information related to a task etc etc.)

Assignees
Jkim I don't think that is necessary for now. I haven't heard any examples explicitly require such roles other than assingees. The only information could be useful is to identify who is in charge or the contact person if there are more than one assignees to a task. Jkim yes.
 * list of users who are assigned to a task
 * Q1: shall we distinguish the task-role of the user in fullfilling the task (assignee, observer, contributor etc etc)
 * Q2: can a task be without assignee e.g. in the beggining while planning of the work is done

Related resources
Various types of resources can be related to a task such as i.e. Files, Wiki pages, Comments, Other tasks, External (non AWOB) resources i.e. via URL etc - to be precised better. Each of these resources could have a separate connection between each other or with other same type of resources related to other tasks.


 * Note: original conceptual model defines separately input resources and output resources, which can then be typed as Wiki or File or a Link

- GL Your names look somewhat RDF-like to me. And for now I'd stick to components actually defined in the model. For example Tag or Topic have not been defined so far and need not be implemented. Same with related project etc. Main components we need to support are File (and Shortcut/BookMark/Link), WebContent. Eventually code and others maybe.
 * Proposal:
 * define separately type of relations which can be linked with a task (not limit it to "input" and "output" resources, so we can be a bit more flexible) and define for which resources these relation types could apply (optional). Below some examples, we may think of ... could help us clarify even better task no 003 (what is AWOB Content)
 * hasInputData (domain: Files)
 * hasOutputData (domain: Files)
 * usesSoftware (domain: Files, bookmarks)
 * hasDescription (domain: WikiPage or Discussion)
 * hasReference (domain: bookmarks)
 * hasDependentTask (domain: Task)
 * isIncorporatedInto (domain: Task)
 * hasTopic (domain: hm? could be some hierarchical categorization or additional grouping)
 * hasTags (domain: user provided tags, could be used throughout a project for tagging various resources and facetted browsing at some point)
 * hasRelatedProject (domain: perhaps other project that relates to this task as well)
 * hasCode (domain: link to a code)
 * agreedOnMeeting (domain: Meeting, this came as idea while reading Task scenarios described at Create task scenarios, vice versa, a meeting can not only have agenda, but also related tasks - i.e. hasDependentTask in this case would be related from a meeting to a task)

Task change-log
Contains the whole history of the task (who did what kind of change e.g. updated a related resource, added/removed a resource, changed assignee, changed status etc..
 * Q1: it is questionable if we need this kind of "change-log" tracking for tasks.. may be interesting for provenance reasons

Simple create task workflow sketch

 * Project Lead(PL) create a task
 * provides metadata
 * goal, due date, assign members if possible, links to input resources if available.
 * System saves a task.
 * Task lead(TL) start the task
 * System creates a task workspace
 * Workspace could be created when a task is created.
 * TL closes task.

Task roles vs access privileges, actions

 * TL
 * can define access, comment permissions to a task for PL(Project Lead), PM(Project Manager), or project member.
 * add/remove assignees to/from task
 * TM(Task member)
 * access, edit workspace.

Meeting minutes

 * Minutes from the meeting on Dec 16, 2011

Model
https://subversion.mpdl.mpg.de/repos/awob/documentation/model/ProjectsAndTasksInLR.jpg

Implementation Model Description

 * Concepts of Projects and Tasks in Liferay need to be implemented as Sites (below brief descriptions, not specifications)
 * So far defined Task statuses - see Conceptual model above (:mandatory, predefined enumerations are 'pending', 'in-progress' 'complete', 'cancelled')
 * Note NBU: there is inconsistency in the Conceptual model statuses, Demo statuses and 0.5 version statuses of a Task - need to be clarified
 * --Jkim 11:19, 2 February 2012 (CET) If there is any change in the use cases from the demonstrator version, i created a new one for the AWOB 0.5. So please ignore those for the demo version if there are the new ones for the awob 0.5.
 * Proposal below: add "open" to distinguish between task-in-definition and defined-task stage
 * --Jkim 14:02, 2 February 2012 (CET) There are two status 'pending' and 'in progress'. How is 'open' different from 'pending'?[1]
 * --GerardLemson 16:47, 2 February 2012 (CET) I agree we don't need to distinguish between "in definition", "definition done, but not yet started" which is what NB seems to imply.

General changes

 * a custom attribute "SiteType" shall be added to the Sites to enable distinction between Projects and Tasks types of Sites
 * a custom attribute "TaskId" shall be added to the Sites to enable quick reference to the concrete Project and concrete Task
 * Sites portlet:
 * option 1: has to be modified to accept as a parameter filtering based on the Site Type
 * option 2: create completely separate portlets for Task Site Types and Projects Site Types

Tasks

 * Tasks portlet is used to define tasks. We can refer to this as "Task definitions"
 * When a "Task definition" is defined in a Site which is a Task type of a site, then it is practically a Subtask definition
 * --GerardLemson 16:47, 2 February 2012 (CET) That would indeed in the future be an obvious way to define sub tasks. Where then the subtask will likely know of the parent task, just as now the "root" task will have to know of the parent project.
 * Tasks portlet i.e. "Task definitions" need to be extended with a custom attribute which provides a link to the Task Site
 * --Jkim 11:51, 2 February 2012 (CET) "Task definitions" is part of the Task site. When a PL or a PM creates a task, one can put contents on wiki or wall, or upload resouces. Thus, when a user selects a 'create task' option from menu, both the option to enter task metadata and to use wiki, wall, resources should be available to the user.

Site templates - two types of Site templates need to be defined in LR

 * AWOB Project Site Template
 * AWOB Task Site Template
 * Resources/Files/Document portlet: has to be created with two folders predefined: Input and Output resources
 * --GerardLemson 16:54, 2 February 2012 (CET) No real use cases defined for resource management. But I'd say that for each task there is a root folder in the parent's folder, named after the task. I guess that what we'd want is that the Project's Resource/File Management component should allow one to see the folders per Task (upon request/allways?). When upoading a resource to the task it will go into the Task's root folder, or a child folder created by the task members. Input and Output must be handled separately. Those will likely definitly become public (to the rest of the project) when the task is completed. This may not be the case with the rest of the task contents. To make this explicit maybe the Task root folder could be given Input, Output and Tmp(or Work) and members can only upload resources inside those folders.

Project Sites Members management

 * as defined for Projects via e-Mail or internal invitation

Task Sites Members management - below options listed
to it, i.e. in the pending phase. There they can volunteer to work on it and the task lead/manager can simply add them. I.e. an invitation/accept/reject model is not required.
 * could be interesting to check if the Project Sites invitation model can be used as well in this case
 * --GerardLemson 16:47, 2 February 2012 (CET) For now we assume that future task members likely have been in discussion about a task before they have been assigned
 * a possibility exists to allow Project members to request membership (i.e. asignments) to work on a task (i.e. on a Task Site)
 * --GerardLemson 16:47, 2 February 2012 (CET) definitly, see previous comment.
 * automated asignments of the members of the Task Site project during Task Site creation (input could be taken from the Task definition assignees)
 * --GerardLemson 16:47, 2 February 2012 (CET) Don't know what is meant by this. "Create Task" action will create the task. Members will generally be assigned afterwards. For now no need to include "member assignment" in "task creation" use case.
 * --Jkim 16:56, 2 February 2012 (CET) if task members are known at create task, the task creator still put them in the system explicitly when creating task.

Site roles

 * basically Site roles are same in LR for both Project and Task Sites (SiteOwner, SiteAdministrator and SiteMember)
 * if these roles need to be shown to the end user, then we have to re-implement accordingly the labelling depending on the Site type
 * --Jkim 12:11, 2 February 2012 (CET) The roles displayed should be the ones defined in [AWOB_Task_006#AWOB_Project_Roles_and_privileges|AWOB project roles]. The scientists would not know what 'site' means.
 * --GerardLemson 16:47, 2 February 2012 (CET) We do need to come to concensus on names. I vote in favour of making naming for task roles as much as possible parallel to project roles. That implies having (as NB defined in miplementation model): TaskLead, TaskManager, TaskMember. The TaskLead is the PL-PM that created the task. A TaskManager can be assigned by TaskLead. A TL-TM (TaskLead or TaskManager) can assign TaskMembers.
 * the re-labeling must be implemented in the Invitations portlet (where Project Lead invites user in a role on a Project Site)

Create a Task Steps (basic proposal for implementation in LR)

 * PL-PM (ProjectLead or ProjectManager) or ProjectMember(PM) (latter to be discussed) Creates a new Task (in LR: A Task entry in the Tasks portlet is created, a Task Site is not yet created - Task Status "Pending")
 * --Jkim 14:02, 2 February 2012 (CET) As discussed before PM is not allowed to create a task.
 * --Jkim 14:02, 2 February 2012 (CET) Please see my comments on Tasks in this section.
 * --GerardLemson 16:47, 2 February 2012 (CET) Indeed, only PL-PM are allowed to create Task on project.
 * PL-PM defines the task assignees via the Task Entry (one task lead - TL and optionally more task members-TM)
 * --GerardLemson 16:47, 2 February 2012 (CET) I would now say, "TL-TM defines the task assignees via the Task Entry". IN particular, a ProjectMember who is not a PL-PM may have been assigned to become a TaskManager and can then assign TaskMembers.
 * TL "accepts" the Task (in LR: A Task Site with TL as the Site Owner and defined TMs as Site Members is created, Task Status changed to "Open")
 * --Jkim 14:02, 2 February 2012 (CET)At the moment, I don't see any reason for a specific step "TL accepts the task". I can see TL could change while a task is in progress. But, this could be dealt simply choosing another TL among task members.
 * --GerardLemson 16:47, 2 February 2012 (CET) It seems that IF we accept the list of roles: TaskLead, TaskManager, TaskMember (let's abbbreviate them to something like: TL, TMa, TMe?), then the TL is always identical with the PL-PM who created the task. In LR this will correspond to the (Task)SiteOwner I guess. The TL role can therefore not be transferred. Instead now a TL can assign someone to become a TMa. But especially, there is no way a TL can accept a task. A ProjectMember (PMe?) can be assigned to be a TaskMember and possibly a TaskManager. But this "acceptance" is not an explicit AWOB action. This in contrast to an AWOB member accepting an invitation to become a Project Member.
 * --Jkim 14:02, 2 February 2012 (CET)Whoever creates a task becomes a task owner. Based on your description on AWOB_Task 006, a task owner is a site owner, and a task lead is closer to a site administrator not quite the same since a task lead cannot change a few task metadata.
 * --Jkim 14:02, 2 February 2012 (CET)Task status becomes 'open'. Please see my question[1] above in this section.

Finish a Task Steps

 * TL or TMA - mark the task as finished (by editing the Task definition )
 * (optionally?)TL or TMA can "choose to make task site available for Project members or not"
 * status: "complete" (somewhere a status "incomplete with reason" had been mentioned)
 * --Jkim 14:02, 2 February 2012 (CET) See my comments above.
 * --Jkim 14:02, 2 February 2012 (CET)Three specific roles for task are defined in Awob Task 006, Task Creator, Task Lead, Task Member. What is TMA? How is it different from the task roles already defined?

Delete a Task Steps

 * A Task can be deleted by the Task creator when in "Pending" status (no further consequences, as Site Template is not yet created)
 * --GerardLemson 16:42, 2 February 2012 (CET) There is no "Delete Task" use case as yet.
 * --GerardLemson 16:42, 2 February 2012 (CET) I do not quite know how to interpret the statemen "as Site Template is not yet created". It MUST be the case that as soon as a task is created, the task workspace is available.

Cancel a Task Steps

 * A Task can be cancelled by the TL or TMA when in any other status but "Pending" or "Complete"
 * --GerardLemson 16:42, 2 February 2012 (CET) The [|"Cancel Task"] use case defines as pre-condition that the task's status is not complete. But it may be "pending".
 * In this case in LR we will have to delete the Task Site and all of its contents (an option would be to de-activate it, but would not go for this option during potential change of the TL)
 * --GerardLemson 16:42, 2 February 2012 (CET) The [|"Cancel Task"] use case defines as post condition that the task and its contents are read-only, but available. So the Site MUST NOT be deleted.

Task Contents Management

 * if wanted, the TL can mark certain contents of the Task Site available for the Project Site members at any stage of the Task Progress (even after it is closed)

Task Members management

 * TL may manage Task members (TM) and give them additionally Task Manager(TMA) role at any time before Task is finished