UC AWOB PM 02 Invite Collaborators

MPDL,GAVO

= UC_AWOB_PM_02 Invite Collaborators - v0.5 =

Comments on Actors
Previously the term PI is used temporarily before deciding on what the awob role should be which is closely related to PI. Since it is decided as Project Manager the use cases UC_AWOB_PM_02_1, and UC_AWOB_PM_02_2 are updated accordingly.

Status/Schedule

 * Status: Specification
 * Schedule:AWOB0.5

Triggers

 * Project Manager wishes to invite scientists to collaborate in his/her project in a particular project role.

Actors
We still use the term PI here to indicate the person leading a project, and who created it in AWOB. For a discussion on the proper (naming of) AWOB project roles please see the AWOB_Concepts_Actor.
 * Project Manager


 * please use the roles of "Project Lead" (not certain if as well "Project manager" shall have this privilege) here --Natasa 15:03, 10 February 2012 (CET)

--Jkim 15:30, 23 February 2012 (CET) Please see AWOB_Task_006.

Pre-Conditions

 * Actor selects a project which is not closed, and in which the actor plays a role of Project Manager.
 * would change this precondition to "one project is selected" (the above one is anyway) --Natasa 15:07, 10 February 2012 (CET)

--Jkim 15:30, 23 February 2012 (CET) Please see the change.
 * would also like to suggest not to introduce "PI" which is a scientific and not AWOB System role, as we agreed that scientific roles are only "labels" which could be different from one project to another - this makes it heavier to understand it for implementation--Natasa 15:07, 10 February 2012 (CET)

--Jkim 15:30, 23 February 2012 (CET) Please read the comments on Actors above.

Flow of Events

 * 1) The actor selects one or more Registered Users from the registered users list or enters email addresses to which wishes to send invitations.
 * 2) The actor  selects the  awob role which the user(s) will get if they join the project.
 * 3) The actor  sees the default invitation text to be sent along with the invitation which may be updated by the actor. The default invitation text is given below. GerardLemson 17:50, 23 February 2012 (CET)NOTE if that text does not conform to the actual imp[emented functionality, this text should be updated accordingly. For example if a link is provided in the email message that should be followed for the invitation to be seen or so, please update this text.
 * 4) The actor submits the invitation.

The default text is as follows:

Dear Colleague,

I would like to invite you to participate in my $project_full_name project. For this project I have created a collaborative site in the online Astronomer's Workbench (AWOB). You will get access to this project site if you accept the invitation.

A short description of the $project_full_name project is as follows:

$project_short_description

If you are an AWOB user, you can accept or decline to join the project through the invitation waiting on your AWOB dashboard.

If you are not an AWOB user yet, and do not wish to participate in the project, please notify me by email of your decision. If you wish to accept the invitation please do the following steps:

1. Please create an AWOB account at $registration_link. 2. If your account is created with this email address, you should find an invitation waiting on your personal dashboard. If not, please notify me of your new AWOB user name by email or using the AWOB messaging functionality. Once I receive your user name, I will invite you again and you can accept the invitation on your AWOB dashboard.

You can find information about the AWOB platform at $link_to_awob.

Best Regards,

$invitor_name $invitor_address

[TODO A scetch of the GUI supporting this use case will be uploaded to SVN. A link to it must be added when it is done.]
 * --Natasa 15:14, 10 February 2012 (CET) please check http://jira.mpdl.mpg.de/browse/AWOB-44 - this would be additionally revised by Rupert
 * --Natasa 15:18, 10 February 2012 (CET)maybe the message shall be re-formulated smth like "Please create an AWOB account at $registration_link if you do not have already. If you already have an AWOB account visit your personal AWOB dashboard and accept or decline the invitation"

--Jkim 16:00, 23 February 2012 (CET) Just asking to create an account is not good enough since when a user creates an account, the invitation doesn't always wait on the user's personal dashboard at the moment(I tried twice, first time the invitation didn't wait on the dashbord, the second time it did. ). The new user must notify the invitor his/her decision as well as the AWOB user name so that  the invitor can re-send it to the user's dashboard. Otherwise, the invitation may get lost.

Alternatives: first send email to non-registered user
This alternative is basically the one supported in the Demonstrator release, without the capability to add a user to a project. Only text of mail may need some adjustment.[the default text here is given on the flow of events.]. Otherwise wait for later use case with capability to link from email to a page allowing first registration, then acceptance/decline etc.
 * --Natasa 15:20, 10 February 2012 (CET) this is already provided as a possibility and the Project Lead can invite both in same step (or separately). Therefore this alternative is no longer valid. For 0.5 we can make one editable message template.

Post-Conditions/Results

 * On the personal dashboard of each invited user an invitation appears. This contains the text of the invitation, the proposed awob role, the name of the project and the name of the inviting Project Manager. A Balsamiq mockup for the list of invitations can be found here
 * An email with the invitation text will be sent to the Registered User with a link to their dashboard where the invitation will appear.
 * On the Collaborators panel/page of the project a list of "sent invitations" appears with the status. The list will contain the person who was invited, date of invitation and status. The proposed mock-up of this list appears Mockup
 * --Natasa 15:21, 10 February 2012 (CET) the last post-condition please move in future developments

--Jkim 18:10, 23 February 2012 (CET) Moved to future development.

Discussion

 * Should Co-I be allowed to invite collaborators? We are discussing this with scientists. Frank Haberl says no.
 * Should the default invitation text include the proposed role? This may be hard to support, as the role is chosen independently of the text through a drop down in the current proposal, which can be changed after text has been updated. GL: IF we have a default role (Co-I according to Frank) we could have the default text include a line that has that role specified. On the other hand, the user might
 * --Natasa 15:25, 10 February 2012 (CET)what we may do for now is the following: in the pull-down list use "Project Manager(Co-I)" as label, in the message we use instead of "Project Manager" "Co-I" (with full title name of course). For Project members we probably do not need anything like this. Would this be applicable?

--Jkim 16:25, 23 February 2012 (CET) For AWOB 0.5, I would use 'Co-I' in the default invitation text regardless of AWOB project role and let the invitor change the text, if necessary. Otherwise people may get confused that Project Manager is defined in a different context from 'Co-I' and may interpret that Project Manager is an AWOB jargon for Co-I.

Future development

 * On the Collaborators panel/page of the project a list of "sent invitations" appears with the status. The list will contain the person who was invited, date of invitation and status. The proposed mock-up of this list appears Mockup.
 * In future, more advanced non registered user invitation.
 * Include more project roles.
 * On the collaborators site, have a list or table of team members with name, email, role, when joined the project, responsible for in the project.
 * provide also a link to the invitation text sent to a each member for PI.

Status/Schedule

 * Status: Specification
 * Schedule:AWOB0.5

Triggers

 * A Registered User sees an invitation on the personal dashboard or reads an invitation email.

Actors

 * Registered User

Pre-Conditions

 * An open invitation is sent to a registered user to join a project.

Flow of Events

 * 1) The actor opens an open invitation that appears on its dashboard by clicking appropriate place.
 * 2) A window opens which displays all the details of invitation, and buttons to accept/decline/undecided[TBD], and an option to add a comment. the mockup.
 * 3) The actor responds to the invitation as follows:
 * 4) If the actor wants to either 'accept' or 'decline' without comments, select the choice according to his/her decision.
 * 5) If the actor needs to communicate with the invitor before making a decision, the actor selects undecided and replies the email sent along with the invitation.

--Jkim 10:48, 24 February 2012 (CET) I moved Natasa's comments below since her comments changed the numbering of steps and made hard to follow the flow of events, and to distinguish the original write up from the comments. If the comments cause to restart list please put them such that at least the original order of steps are preserved.
 * please move the previous steps to "future development". Use smth like following for 0.5 (see http://jira.mpdl.mpg.de/browse/AWOB-169 ) :


 * 1) The Registered User sees an invitation on his/her personal dashboard, containing information about the invitor, project and the role for which s/he has been invited in the project, and a possibility to accept or reject (decline?) the invitation
 * 2) The Registered User 'accepts' or 'rejects' the invitation
 * 3) The Registered user optionally provides a short comment.
 * please move the comment to "future development". Use "Alternative" proposal (see below) for 0.5

Alternatives

 * --Natasa 15:33, 10 February 2012 (CET)optionally) the Registered User responds to the invitation email which s/he received before or after accepting/rejecting the invitation from the personal dashboard

Post-Conditions/Results

 * 1) The invitation's status and other relevant metadata are updated in the project's list of invitations according to the choice of the invitee. For details of this see the conceptual model [TBD need link here that does NOT show the figure in the page] and the mockup. It will include whether user has accepted/declined, the comment the user wrote, the date when the decision was made.
 * --Natasa 15:35, 10 February 2012 (CET)please move the above postcondition in the future development


 * 1) If the Registered User has accepted the invitation:
 * 2) the system grants the privileges to the Registered Userfor the project corresponding to the proposed role.
 * 3) The project of which the Registered User now is a member appears on the "Projects" list on the Registered User dashboard.
 * 4) The Registered User appears in the list of project members on the project's collaborators page
 * 5) The invitation disappears from the list of invitations on the Registered User's dashboard.

Discussion

 * In the current scope of AWOB 0.5 I think that there is no way for invitors to find out whether their invitations sent out  are declined if an invitee (who is an AWOB user) responses via his/her dashboard (correct me if i am wrong). The only way to do is to send a separate email to decline.


 * I think that we should give an option to provide a reason not accepting an invitation or accept with a different project role from the proposed one.
 * the reason is now included in the use case description. Would not recommend accepting with a different project role, a request for another project role may be verbosely stated in the rejection reason. Then a new invitation will be sent.--Natasa 09:51, 7 July 2011 (CEST)
 * Agree with your recommendation except that a new invitation MAY be sent. --Jkim 10:49, 7 July 2011 (CEST)


 * The invitation not only proposes a role in the project also could include other details such as what kind of works the invitee are expected to do in the project. Therefore, the invitee should have an option to accept the invitation with comments. In such a case the PI can send another invitation.
 * The invitation text should be personalizable since it can include what the PI proposes to an invitee to do what in the project.
 * What we may want to add to member management (though needs careful discussion) is whether a user's role can be changed (long) after accepting and whether a member can be removed from a project. These would require new use cases but might deal with some of the discussion points - Jai Won and Gerard 2011-12-07.
 * Should it be possible for a Registered User to see on the personal dashboard all old invitations to her/him that were accepted/declined?
 * Should the user be able to remove closed invitations? Needs only a remove button on non-pending invitations.

Future Developments

 * option to provide a reason not accepting an invitation or accept with a different project role from the proposed one.
 * in addition to pending invitations on a personal dashboard a user can see all the invitations responded, and a way to remove past invitations as a user wishes.
 * needs a project member management which enables project manager to change an AWOB project role of a project member.
 * project invitation status available to project manager: list of invitations sent out in a project displaying invitation metadata including
 * status whether an invitation is accepted/declined/...
 * to whom/email the invitation sent out.
 * etc.

= UC_AWOB_PM_02 Invite Collaborators DEMONSTRATOR =

Status/Schedule

 * Status: Specification
 * Schedule:Demonstrator

Triggers

 * A project PI wishes to invite scientists to collaborate in his/her project in a particular project role.

Actors

 * PI

Pre-Conditions

 * One project is selected
 * Selected project is not closed

Flow of Events

 * 1. The PI selects one or more Registered Users from the registered users list.
 * 1.1. For each selected user the PI defines the role (Project member) in which the registered user is to be invited for collaboration.
 * 2. The PI may write a text of the invitation, to be sent along with the invitation
 * 3. The PI confirms the invitation action
 * 4. The system sends notifications to all invited users and displays a success message. The use case ends successfully.

Alternatives
''
 * 2.1. The PI modifies the default text of the invitation (provided by the system), to be sent along with the invitation
 * ''Note: optional, can be predefined by the system and customized for each project

Post-Conditions/Results

 * Notification is sent to each invited Registered User.
 * A sent invitation appears.
 * Mockup

Future development

 * In future, registered users can be invited for collaboration in other project roles, such as Project member, PI, Co-I.

Triggers

 * A Registered User sees a pending invitation on the personal dashboard.

Actors

 * Registered User

Pre-Conditions

 * A pending invitation exists for a registered user to join a project.
 * A pending invitation is selected.

Flow of Events

 * 1. The Registered User has a choice to accept or to reject the invitation.
 * 1.1 The Registered User accepts the invitation with the proposed project role.
 * 1.2.The Registered user provides short comment and rejects the invitation.
 * 2. The system grants the privileges for the project accordingly to Step 1.1.
 * 3. The system updates the status of the invitation accordingly to Step 1. The use case ends successfully.

Alternatives

 * None

Post-Conditions/Results

 * The pending invitation is no longer displayed on the Registered user dashboard.
 * The accepted Registered User sees the project on its dashboard's list of Projects.
 * The accepted Registered User appears on the project page's list of members as with its project role.
 * The system puts the accepted Registered User on the list automatically.

Discussion
the proposed one.
 * I think that we should give on option to provide a reason not accepting an invitation or accept with a different project role from
 * the reason is now included in the use case description. Would not recommend accepting with a different project role, a request for another project role may be verbosely stated in the rejection reason. Then a new invitation will be sent.--Natasa 09:51, 7 July 2011 (CEST)
 * Agree with your recommendation except that a new invitation MAY be sent. --Jkim 10:49, 7 July 2011 (CEST)


 * The invitation not only proposes a role in the project also could include other details such as what kind of works the invitee are expected to do in the project. Therefore, the invitee should have an option to accept the invitation with comments. In such a case the PI can send another invitation.
 * The invitation text should be personalizable since it can include what the PI proposes to an invitee to do what in the project.