UC AWOB PM 04 SPEC Create Task

MPDL,GAVO

=Change in Task for R0.9=

Change labels and GUI of task menu items

 * R0.9


 * 1) Goal
 * 2) Make it a text field instead of text area in GUI just like ‘summary’ of JIRA ticket.
 * 3) Overview
 * 4) Replace it by ‘Description’
 * 5) Work
 * 6) Next to it have an icon to indicate that ‘Work’ is a protected folder.

Improve task list

 * R0.9

Jaiwon Kim(Lead) Gerard Lemson(Manager) Theo Testor, John Doe
 * 1) Instead of listing task members in separate columns one for each task role, list them in a single column name ‘members’
 * 2) member name and his/her role next to his/her name
 * 3) Example

Make task ID human readable

 * R0.9


 * 1) It is hard to remember to task ID in particular selecting resources from ‘Browse server’ interface since only task ID shows on the interface.  Make it start from 1 integer increase by 1.

= UC_AWOB_PM_04 Create Task - v0.5=
 * Related AWOB Task AWOB Task 007

Status/Schedule
Applied to all the following use cases on this page


 * Status: Specification
 * Schedule:AWOB0.5

Actor

 * Task Creator
 * would use here "Project Manager", "Project Lead" - if these are the only ones who can create tasks in AWOB --Natasa 16:43, 9 February 2012 (CET)

--Jkim 13:09, 10 February 2012 (CET) Please follow the link.

Precondition

 * Project is not 'closed'.

Trigger

 * the actor wants to create a new task in the project

Steps

 * An actor clicks 'create a new task' on the tasks page on a project and is led to a form with the definition metadata. (See 'Definition' on AWOB_Task_007, https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/mockups/Axure_Mockup/index.html and Conceptual Model on AWOB_Task_007.)
 * In the create task view the following fields (see Task class in the conceptual model) should be editable (NOTE It should be clear on the GUI which fields are mandatory and which are optional):
 * goal (mandatory)
 * priority (mandatory, default = 'medium', see TaskPriority in the conceptual model.)
 * status (mandatory, default = 'pending' see TaskStatus in the conceptual model.)
 * visibility (mandatory, default = 'project' see TaskVisibility in the conceptual model.) (See discussion below.)
 * deadline (optional, default = '9999.12.31' or something like that)
 * estimatedDuration (optional, default = NULL)
 * The following fields are not explicitly settable. They are set as result of other use cases such as "start task". They show up on this GUI as non-editable fields:
 * startDate
 * closingDate
 * would add here explicitly which metadata exactly (in scope of 0.5, see below) and the step "the actor optionally defines the Task Manager or Task Members" of the task --Natasa 17:10, 9 February 2012 (CET)
 * Jkim 13:44, 10 February 2012 (CET) Done.
 * Jkim 13:44, 10 February 2012 (CET) Task members are not assignable from this Create Task GUI. This is part of the Workspace area of the Task, similar to Project Member
 * --Natasa 14:55, 10 February 2012 (CET) sorry, but this is not in Axure prototype, and is in the GUI Layout (slide 10 in the presentation) - we already have efforts on its implementation accordingly, therefore lets keep it still optional (depending how far we are, at the moment can not give a valid status). The workspace would anyway have to allow additionally the task membership management
 * --GerardLemson 15:36, 10 February 2012 (CET) Precisely for this last reason, as well as to be as closely conforming to Project creation and Project Membership assignment as possible, and to not have multiple places where Task Members would be assigned, we believe it is better not to overload the Create Task GUI component. The fact that the mockups are not up to date should not be a complication. They have not been discussed in detail yet. But IF you are so far already in the implementation to also allow this task membership assignment on the Create Task GUI component, so be it. As long as this does not mean that this is the only place/time that members can be assigned. It MUST be possible to add members after the creation of the task.


 * After entering information an actor clicks "submit".
 * If it is valid request (:--Natasa 17:24, 9 February 2012 (CET) what means if it is a valid request?, do we need some extra validation apart from optional/mandatory?)
 * Jkim 13:44, 10 February 2012 (CET) No, only optional/mandatory (for now).


 * The system creates a task, assigns a unique ID, and sets 'systemCreateDate' and 'creator' of the task.
 * The actor is sent back to "Task list" of project where the new task appears as the first item of the list.
 * Jkim 13:50, 10 February 2012 (CET) Alternatively: the actor is sent to the Task's workspace.
 * Jkim 13:50, 10 February 2012 (CET) deleted comment from Natasa regarding notification.


 * If it is invalid, the GUI indicates the errors, allowing the actor to correct these.


 * --Natasa 17:24, 9 February 2012 (CET)would state the following metadata that need to be provided during the creation of the task:
 * Jkim 13:50, 10 February 2012 (CET) done this explicitly above

Post conditions

 * A task workspace is created. It has task metadata, wiki, wall, related resources folder as shown in the mockup https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/mockups/Axure_Mockup/index.html.
 * when a task is created we can create a "restricted" and a "private" area for the task


 * "restricted" area are readable to all project members (including task members, task lead and task manager) but only editable when the visibility of the task = 'project'.
 * "private" area is only visible and editable by the task lead, task manager and task members
 * when users go to their task workspace, after the creation of the task, they would be able to upload resources related to the task (we would not do it during task creation step in 0.5) --Natasa 17:31, 9 February 2012 (CET)
 * --Jkim 12:16, 13 February 2012 (CET) I thought that 'restrict' and 'private' areas meant 'public', and 'private' walls. But reading the comments (copied below) again from UC_AWOB_PM_09 Change Task Status- v0.5, I misunderstood. What are 'restrict', and 'private' areas?

--Natasa 18:22, 9 February 2012 (CET)Would suggest rephrasing the postconditions (as these are switching from pending/started) and taking another view on this (referring here also to create task use case)

when a task is created we can create a "restricted" and a "private" area for the task "restricted" area are all project members (including task members, task lead and task manager) "private" area is only visible by the task lead, task manager and task members in this case the visibility status of the "restricted" area does not have to be switched to "private" (in our opinion it makes no sense to hide information which was already visible to the users)

Jkim 14:19, 10 February 2012 (CET) Changed the post conditions on Create Task use case as suggested.
 * The actor becomes the taskCreator of the created task. See conceptual model
 * The new task appears on 'Task list' of the project.
 * Send a notification to a personal dashboard of task assignees if any.
 * --Jkim 12:07, 2 February 2012 (CET) email notification is NOT required.
 * The new task appears on the 'Task list' on the personal dashboard of each assignee --Natasa 17:33, 9 February 2012 (CET)
 * task asignees are anyway seeing the new task on the personal dashboard. Explicit notification would be questionable for 0.5 --Natasa 16:57, 9 February 2012 (CET)


 * Add an event on project calendar if deadline is provided.
 * questionable for 0.5 --Natasa 16:56, 9 February 2012 (CET)
 * Jkim 14:18, 10 February 2012 (CET) Pushed to Future Developments


 * The new task appears on 'What'new' of the project.

Future Developments

 * Once task is created and deadline is proved, add an event on project calendar.

Discussion
In Conceptual Model on AWOB_Task_007 the default visibility for task is 'task'. This is meant to be that all the task contents are accessible to only task members by default. But when a create is created and its status = 'pending' assume that its content are still accessible to all the project members except the private task wall.
 * The default task visibility:
 * Is there a difference between "Task Member" and "Assigned Task Member"? - otherwise we would need to use consistent names (Task Member had been agreed as Actor/Role name for the task)
 * --Jkim 10:28, 3 February 2012 (CET) They are defined in AWOB_Task_006 and AWOB_Concepts_Actor. Both of them are task members but i gave different names to distinguish actors from roles.
 * System notification can happen only in case there are task assignees defined
 * A question: what is the form of notification? (e-mail ?) Normally, the personal dashboard of the user will show in the "Tasks" part all tasks assigned to the user.
 * Task wall
 * The scientists agree that it is useful to have two separate walls for discussion, one which only task members can read and write on, the other for gathering comments/discussions from all project members.
 * For AWOB 0.5, Natasa mentioned that it would be hard to implement for each task having two walls. Therefore, we agreed on [TBD to confirm] to implement a single wall for task members only. For project member's comments use [TBD ]...
 * --Natasa 17:28, 9 February 2012 (CET)would like to correct this statement: We have found a way to implement two walls via Message boards LR feature. We will create by default two threads (one public and one private). Both would be visible to the end users (according to their privileges)
 * Jkim 14:16, 10 February 2012 (CET)OK. Updated the first item on Post conditions.

= UC_AWOB_PM_04 Create Task - DEMONSTRATOR=

Overview
During a life cycle of a collaborative scientific project there are many tasks and todos as in business or software development project. However, a scientific project usually does not use a complex tool to manage its todo list as in business or software world. The bigger a project is the more formal management is. In awob we like to support a simple but sufficient way to manage tasks. Also it should take into account characteristics of a science task. For further details see Task in AWOB_Concepts_Project.

Who can create a task in a project could depend on how a project works. The larger it is usually it becomes more formal. For example, only a PI of a project can create and update tasks in one project. In other cases, all members of a project can both create and update them.

In demonstrator, we will assume that only a PI of a project can create a task.

Related Conceptual Model and GUI

 * Conceptual model Task in AWOB_Concepts_Project
 * GUI https://awob.mybalsamiq.com/projects/projectpageextentions/TODO+List

Status/Schedule
Applied to all the following use cases on this page


 * Status: Specification
 * Schedule:Demonstrator

Actor

 * PI

Precondition

 * A project is selected.
 * Project status must not be 'closed'.

Trigger

 * It is decided within a collaboration (or by single scientist) that some tasks is required for the project.

Steps

 * An actor clicks 'create a new task' on the page and is led to a form.
 * An actor enters necessary information on the form. For the list of metatdata see AWOB_Concepts_Project
 * group
 * goal: mandatory
 * creator: list of the names of PIs, mandatory
 * taskAssignees: list of the names of all the members of the project. Multi selectable
 * status(:mandatory, predefined enumerations are  'open', 'not started', 'started', 'completed', 'incompleted with reason', 'other'
 * Priority: highest, high, medium, low
 * createDate: the system provides.
 * dueDate: planned date to complete the task.
 * notes: initial detailed description of the task if necessary and followed by discussions as needed.
 * inputResources: link to the uploaded resources if exists
 * Please precise the list of the metadata inline in the use case description so that it can fit in the scope of the demonstrator.--Natasa 12:20, 5 July 2011 (CEST)
 * Need a way to upload html.--Jkim 11:39, 11 July 2011 (CEST)


 * After entering information an actor clicks "submit".
 * If it is valid request an actor is sent back to "TODO list" page where the new task appears as the first item of the list.
 * The System sends a notification to the Project Member to whom the new task is assigned.
 * If invalid an actor corrects errors and resubmit.
 * The first two steps are superfluous in this use case. These are already included somehow in the precondition and in the use case trigger description. Proposal to remove them --Natasa 12:26, 5 July 2011 (CEST).
 * As long as the steps are clear, we can remove the first two steps.--Jkim 11:17, 11 July 2011 (CEST)

Post conditions

 * Upload resources if input resources exist.
 * Send a notification to a personal dashboard of task assignees.
 * Browse Tasks.
 * Edit Task.(?)

Discussion

 * In the future 'group' should have PI defined enumerations. Possibly tree view by group.