AWOB Task 008

MPDL,GAVO

General Information
Grouping: Short description:

Links

 * conceptual model diagrams
 * awob consortium model: https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/AWOB_consortium_concept_model_2012sep20.png
 * updated awob conceptual model: https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/AWOB_project_conceptual_model_2012sep20.png
 * Use cases:
 * Discussion from the f2f meeting on Sep 21, 2012 https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/consortium_usecases_2012Sep21.pptx
 * Manage Consortium
 * Discussion from the f2f meeting on Sep 21, 2012 https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/consortium_usecases_2012Sep21.pptx
 * Manage Consortium

Discussion

 * it may be interesting to check if the consortia actually shall be set-up as a special instance of AWOB on its own
 * to better understand it, it is important to also understand the need and nature of the hierarchy of the projects - is it indeed a hierarchy or it shall be considered as another model of grouping of users etc.

 IN PROGRESS 

= Add support for ‘Consortium’ to AWOB – Use Cases =

Consortium in astronomy is an association of institutes and their interested members, or group of scientists from various institutes with a common scientific objective and sharing resources and data.
 * Depending on the size of a consortium its organization can be hierarchical.
 * For a small one there is no hierarchy in organization. It is similar to a project consists of PI(s), Co-Is, members and produces multiple publications..
 * For a large one there are groups, each of which specializes in a specific scientific area, or a technical support, etc. If necessary it is possible to have sub groups in groups. eg, a WG called 'galaxies and clusters' can have two sub groups 'galaxies', 'clusters'. Also there can be a steering committee for reviewing memberships, advising, and assisting PI in its management, and policy making, etc.
 * For the initial scope of consortium support within AWOB is managing members and scientific projects within a consortium.

Definition of Consortium
A(n AWOB) Consortium is a special kind of (AWOB) Project
 * Consortium members
 * Group of people (members) who have some access rights to consortium data, resources, activities(internal systems, discussions, meetings, mailing list), its project list and publication archive, its private (awob) workspace.
 * Members may leave or join a consortium during its lifecycle.
 * External collaborators
 * not a member of WGs if there are & not a consortium member.-> No access to consortium private workspace or internal system, resources, activities.
 * can access to only consortium data & resources that are given permission by PI or authorized consortium members.
 * usually time limited
 * it could be individual or group
 * External collaborators may bring external data to work with.
 * Depedning on its size it can 0...N levels of groups, each of which consists of members of the consortium.
 * If there is such groups,we only consider one layer of those groups for now which are henceforth called working groups(WGs).
 * each WG has chair(s), optionally deputy chair(s) and members. (see egs http://www.satellite-planck.it/content/view/78/95/ or eRosita cluster group 1 chair, 2 deputies)
 * WG manages scientific projects: proposes them, announces them
 * If there are sub groups in a WG any scientific projects are most likely managed in a WG level(ie., approval by WG chair), not in sub group level.
 * A "scientific" paper/project must be associated w/ a WG.
 * If absolutely necessary, a new WG is created.
 * If there is no substructure[Ask FH]
 * PI[ & Co-Is] mananges projects:
 * awob project vs WG
 * consoritum members can use an Awob project not for a 'scientific' paper but for writing a white paper, for exmaple. In such cases, it's plausible that it is created outside of a specific WG.
 * Consortium Publication Archive
 * Regardless of its size it keeps track of all the publication both in progress, or published.
 * List of publications produced by Consortium, not necessarily all created in an AWOB Project.
 * Provide an option to upload paper as eg. pdf directly to the archive in case there is no AWOB project managing its creation.
 * Types (Which types of publication should be uploaded on a publication archive may differ from consortium by consortium)
 * Scientific papers
 * Technical papers
 * Colloquia, Conference presentations, and conference proceedings
 * Thesis
 * etc
 * Need to flag to distinguish typs.
 * need to provide some metadata for papers: authors, status (draft/submitted/accepted?), comment (from authors)
 * author list
 * title
 * [TBD] see natasa's link
 * Papers produced in AWOB project can be added to archive with a link to the paper in the project.
 * in a sense it is announcement of result of project, possibly with option to add comments to public discussion list for project. non AWOB-project-papers can only be discussed in consortium discussion threads.
 * For non awob papers we need to support
 * store the publiation metadata listed above. The metadata should be provided/entered by authors.
 * For discussions of a paper, we should give an option to the authors to create an awob project. If they chose not to however they do it is not AWOB's concern.
 * [Q]Who can upload papers.
 * If WGs exist
 * Workgroup leads(meaning WG chairs) only or any consortium member? [TBD]
 * In order to create a draft it is safe to assume that its abstract/proposal to write a paper was approved by WG chair or PI. For that reason 'draft' can be uploaded by either WG chair or one of the authors.
 * Otherwise [Aks FH]
 * Consortium Member management
 * Since it is not guaranteed that all consortium members will be AWOB members, it is necessary to support full consortium member list in consortium.
 * Name, email, institute, link to awob member if he/she is. Scientific status(PI, project scientist, WG chair, etc), participating WGs, papers?, projects(if awob member), etc[TBD]
 * Add/Remove members from the list.
 * What involves removing a member if he/she is an awob member.[TBD]
 * Able to synch the member list w/ consoritum mailing list.
 * able to upload the existing list(eg., excel sheet, csv) to awob.
 * able to upload the existing list(eg., excel sheet, csv) to awob.

Questions/Comments

 * What is a consortium in general (not seen with AWOB eyes)? Is it a set of organizations/institutions forming a consortium, and selected members of these institutions are also members of the consortium? Or a combination of institutions, commities, people? e.g. see Wikipedia definition --Natasa 09:57, 31 July 2012 (CEST)
 * Jkim 17:26, 3 August 2012 (CEST) more of the first of the two or people from various institutes. See above.
 * what are multiple levels of groups within a consortium,the current implementation does not have to fulfill all levels, but it is important to keep that in mind upfront. Also, is it clear that these are related in strict hierarchy or these are arbitrary groupings of people? Please give some examples. --Natasa 09:57, 31 July 2012 (CEST)
 * Jkim 18:17, 3 August 2012 (CEST)
 * A large consortium has a hierarchical organization(see above) in particular organzing scientific projects and activities. However, it is also forseeable that there might be a case to create a group for a purely managerial purpose if the members choose to. In such a case we can still use AWOB 'WG' concept.
 * [GL] COMMENT ON THIS.
 * For a small one usually a consortium has several (awob) projects or publications.
 * in some discussions "core" members and "regular" members where mentioned. Please precise what are these and how they relate to consortium, project, working group, other kind of group etc.?
 * Jkim 18:17, 3 August 2012 (CEST) mostly related with how much data access right a member has. Most likely 'core' or 'senior' members lead working groups.
 * Publications which are created outside of a project, but are somehow "affiliated" to a consortium are part of the consortium publication archive. Are publications created from a project automatically part of the consortium publication archive?
 * Jkim 18:17, 3 August 2012 (CEST) This could depend on consortium policy. There is some quality control by PI or whoever responsible. For eRosita only if approved by WG chair. But for small one ?[ask FH, Planck, SDSS]
 * If a publication is related to a project of a consortium, could it be that a publication may be related to several projects of this consortium?
 * Jkim 18:17, 3 August 2012 (CEST) It is the other way: a project may produce one or more publications. However, it is possible that a publication uses a result from other publications or projects. Then they should appear on references, and the author list should be provided explicitly by themselves.
 * What are the affiliations of the publications in this case? Is it the affiliation of the institutions of authors or consortium or both in a certain sense?
 * Jkim 18:17, 3 August 2012 (CEST) Usually it's an author list, each author with his/her affiliation. But users themselves should provide them how ever they should be.
 * "non AWOB-project-papers can only be discussed in consortium discussion thread" - but who would prevent a project team to upload a non-AWOB-project paper in own resources and discuss them within their project? Or, a non-AWOB-project paper can be referenced via a shortcut in project resources (that is if there is a relevance to the project).
 * Jkim 12:30, 8 August 2012 (CEST) However they use AWOB to discuss their paper (they well maybe just use emails) it's their problem. As mentioned above we'll provide an option to create a project from the archive for uploaded draft/paper in the archive.[JK write usecase][GL] Confirm this.
 * [NB] Therefore, the discussion can be only visible in this case to the project members. Are we going to have another visibility level such as "consortium" visibility for assets such as "resources", "discussions", "epublications", "report" ...?
 * Jkim 12:30, 8 August 2012 (CEST) Regardless of how people use the awob, we should provide a way to open discussions to the consortium members & optionally other components as you described. [Which components/assets & how TBD].
 * Can a consortium have other types of resources (similar to task/project resources) in addition to the publication archive? What are the rules in this case? Everyone who is member of a consortium may upload files or not?
 * Jkim 13:58, 6 August 2012 (CEST) Most roject components in AWOB should be available for a consortium. i.e., What's new, Overview, Collaborators, Calendar, Discussions, Resources. (Some components may need to be modified.)
 * Concerning tasks: 'consortium' and 'wg' level tasks are more likely 'activities' (or simple todo lists) BUT in the first implementation we don't support consortium level tasks/activities. I think that we should support for WG level.
 * [GL] COMMENT it
 * In addition, it needs list of projects ( & publication archive) and organization view(eg., list of WGs, participating institutes and contacts) if necessary. I think that all consortium members can upload files in consortium resources but who can access them depending on file content, consortium policy, size. (see below the use scenarios.)
 * Does a consortium has public, restricted and private space?
 * public - information visible to general public
 * Jkim 13:58, 6 August 2012 (CEST) Yes. Usually a place for overview and latest news from a consortium. However, when the public page is created should be left to a consortium lead.
 * restricted - information visible to all members of the consortium and all members of the projects related to the consortium - this obviously, only if member of a project does not have to be a member of a consortium. Is there such a case i.e. are consortium members containing set for all project members of all projects within a consortium?
 * Jkim 18:07, 6 August 2012 (CEST) So far i haven't seen use cases to have restricted page.
 * private - information visible only to members of the consortium


 * Who can create a consortium? Any User at present can create a project. Potentially, any User can also create a consortium?
 * Jkim 18:07, 6 August 2012 (CEST) I think so. A consortium is not necessarily very large, there could be 20 people in it.
 * How is the membership in the consortium managed (one or any of see below ...)?
 * invitation of users within a consortium?
 * Jkim 18:07, 6 August 2012 (CEST) By invitations. Within a consortium A consortium member he/she can request to join a scientific project once announced/uploaded publication archive to consortium members.
 * registered users may request membership within a consortium (in this case, would a consortium be visible to registered users only, or to general public)?
 * Jkim 18:08, 6 August 2012 (CEST) No.


 * Who can create a working group? Any user who is member of a consortium or only some users of the consortium with special privileges?
 * Jkim 18:07, 6 August 2012 (CEST) most likely consortium lead. not any members.
 * Can a member of a working group be "external" user who is not a member of a consortium in regular case?
 * Jkim 18:07, 6 August 2012 (CEST) No. See above or below


 * Can a project be created in a consortium, but outside of a working group? Is this process it sequencial i.e. can it be that someone in consortium has an idea about a project, it is discussed, then a WG is created from interested people?
 * Jkim 18:07, 6 August 2012 (CEST) Yes in the following cases
 * if WGs do not exist in consortium.
 * if WG exist
 * consortium members are one or more WG members. Therefore, a scientific project is always created in a WG.  if somehow there is a need to explore a new area of scientific interest then it is possible to add a new WG.


 * Please draft a list of expected information in Consortium workspace? (public, private, restricted)
 * Please draft a list of expected information in the WG workspace?
 * Please draft a list of expected information in the Consortium project workspace.


 * Ah, OK, some things are already provided below, but please simply read it through, it may turn up some stuff is still not briefly described. my comments below as well..--Natasa 10:11, 31 July 2012 (CEST)

Life cycle of a publication in consortium/workgroup/project
The following publication life cycle is mostly relevant to scientific papers. The publication life cycle is only supported if publication is produced by an AWOB Project which then manages it.
 * (for now?) we need not support any life cycle management of publications outside of an AWOB project. If users want to manage a publication's lifecycle they only need to start a project for that.
 * publication lifecycle has various steps, some of which related to submitting publication to a journal:
 * These are the phases of a project to publish in a journal so far identified and required to support in AWOB.
 * Approved title, abstract, current project members, identify the project leader
 * Draft/Open for comments
 * Submitted to Journal
 * Revised & submitted due to the request from Referees
 * Natasa:the revised status may become irrealistic, as it depends on the work discipline of the end user. What we could suggest is, if the user uploads a new version of the fulltext (and that can be in any of these statusses) - a version is automatically created.
 * Jkim 17:24, 8 August 2012 (CEST) I meant 'revised and submitted'. For uploading revised version(here updated version) then a new version should automatically created.
 * Accepted/Published


 * AWOB must keep track of all the dates & automatically stored and make them available whenever the status changes.
 * [Q]: do we need to track these for non-AWOB-project publications only as metadata on the publication archive?[TBD]
 * Jkim 17:24, 8 August 2012 (CEST) I would assume to keep track of the date time whenever the file is uploaded. For changing status to pending/approved and draft, it is reasonable for the system to keep track of date time when the status changes. For submitted/revised/accepted it could be either the official date time which appears on the journal, or when the user enters into the archive.
 * [AM] In publication archive there is no need to enter the official date time because that is available in the published paper. Having a couple of days difference in those date time is not a problem. Therefore, keeping the date time set by the system whenever the status changes is good enough.

--Natasa 10:28, 31 July 2012 (CEST) Comments below only apply to non-AWOB publications i.e. not ePublications.
 * we do not have question the metadata vs. fulltext so strictly now, but we could certainly recommend users to put also the fulltext and not only the metadata. thus this can also be searchable better.

-- Jkim 17:53, 8 August 2012 (CEST) I am not sure uploading the full text is plausible since it will be in latex, and there are figures, plots.

--Natasa 10:28, 31 July 2012 (CEST): related to status change: usually in a publication archive, users do not always provide the data on status change timely. We had such a problem in PubMan already. What we enabled, is only metadata which describe different dates and separately a "publication" status. Thus user may enter information at any time available, and is not bound to a strict workflow, in practice it is very heavy. The system however, tracks the date when a new version of the document is created (being update in any metadata, or upload of new fulltext file).

-- Jkim 17:53, 8 August 2012 (CEST) Rough date time is enough. See above [AM].

--Natasa 10:28, 31 July 2012 (CEST): for not AWOB ePublications there still may be an AWOB workflow, which means: users may deposit any non-AWOB publication, and someone has to approve if this can go into the consortium archive. Additionally, it does not matter if this non-AWOB publication is in status draft, open for comments or submitted or already published in a journal. Perhaps users can also put their discussions. It's just a different level. Would suggest we reconsider this, as we have some time ahead for ePublication implementation, whereas users can already discuss publications created from Project which is based in AWOB and deposited in Consortium publication archive (or Project publication archive?).

Specifically

1. Approved

 * a consortium member appears(for awob project)/enters(non-awob one) once a project is approved.
 * title, abstract, current project members, identify the project leader
 * Estimated duration[TBD]

2. Draft

 * Open for comments by consortium members.
 * Upload draft to somewhere ANY consortium member can review.
 * Either upload pdf format of a draft or use 'ePublication' area.
 * Would be good to have a specific 'discussion' area for this purpose only for awob project.
 * Make selected awob project components available to any consortium members.

3. submitted

 * Submitted to a journal.

4. Revised?

 * Revised due to the request by referees
 * Store whatever information required.
 * Keep all the revisions.

5. Accepted/Published

 * make the link to journal available on publication archive.
 * etc.

Project in a consortium
For a project in the context of consortium, it is necessary to support a way to specify status in the lifecycle of a project. Also need to indicate whether a project is editable or not using a flag like 'open/closed'. The status are
 * Pending/ Proposed
 * Approved
 * based on the information provided below (approved is not explicit state of the project, and WG members discuss the project proposal, i see no reason to track these two statuses right now, unless for some very specific reason?). Normally, in the WG discussion boards, as well in the WG Workspace (e.g. as a Task or as a Wiki) - some information can already be gathered. Haveing a project in status "pending/proposed" or "approved" means - a project must be created, and there is a regular workspace with all other project-based information. This is also fine, but then "approved" is also a status and not only a consequence of an announcementm right?

--Jkim 17:23, 6 September 2012 (CEST) 'approved' could be an action which changes the status of project from 'pending/proposed' to 'in progress'. I crossed 'approved' from the project status. Jkim 13:37, 10 October 2012 (CEST) However, some consortia do not require project approval. Therefore, it might be better not to implement explicit action 'approve'.


 * In progress
 * Completed
 * Cancelled

Specifically,

1.Proposed/pending
--Natasa 10:45, 31 July 2012 (CEST) there is a possibility for users to request a membership to a project, if the project is of type "restricted". Current AWOB projects are "private". A difference between a private and restricted project is: private project is visible only to its members, restricted project is visible to a "set of users". "Visible" here means, notion about the existence of the project, not necessarily all project workspace. Consortium projects are not "private" as can be seen by all consortium members, right?
 * One or more WG members have proposed a project on the mailing/discussion list of WG
 * discussion is taking place, leading possibly to the tentative decision that a [project can be defined
 * In AWOB the WG lead/manager creates a project, in state "proposed" (or "pending" ?).
 * [Q] who can create a project in WG?
 * [GL] Only WG manager/lead. This will create a project plus an automatic association in the WG's projects collection.
 * [JK] It is also possible for a few consortium members to come up with a project idea, and the supposedly 'lead' creates a project. In this case, the WG lead must be given a project manager role.
 * The project appears in WG's "Projects" table as 'proposed'.
 * there should be an option to approve the proposed projects by working group chair(in awob role working lead/manager).
 * A project is approved by the relevant WG chair, who announces it to the Consortium.
 * 'Approved' is NOT an explicit state on a project. It is an implicit consequence of it being announced to the Consotrium.
 * --Jkim 15:58, 28 August 2012 (CEST) should be an action.
 * The project now appears on consortium level project. (specifyies 'WG' it belongs to).
 * The project is open for requests to join it from consortium members. (For joining a project or inviting members is described in use scenarios below). This is done by simple messages to the project lead.  Project lead can then send inviatation in standard manner.

--Jkim 15:58, 28 August 2012 (CEST) The list of all consoritum projects should be available to all consortium members. However the project content should be available only to the project members.(ie., private). In the future AWOB should support the feature that the project lead can give a consortium member a temporary membership to the project (like restricted) if some consortium member wish to learn more about the project in order to decide whether to join the project or not.


 * [Q] is this open invitation or could the request be turned down by the project lead?
 * [AM] YES
 * [Q] until which phase this option is available?
 * [AM] Until 'submitted'
 * [GL] AMs response refers to a publication state. I would say: until project is 'closed'/'cancelled'
 * OK, so this clarifies, as any user can join a project at any time (as long as the project is not closed/cancelled). However, user can not join a project if the project is "pending/proposed". We probably need to consider what we gain if we track projects with status before project is approved, and what we loose of we don't - i.e. if we start tracking the project as such from the moment a project idea is actually "approved" to become a project.

--Jkim 15:58, 28 August 2012 (CEST) For pending/proposed project, consortium members shouldn't be allowed to request to join the project but it shoud be still possible for consortium members to join the project lead or manager by invitation if necessary.
 * [GL] comment it
 * Hm... could be nice category, "project ideas" for the workgroup discussion board. Once a thread in this category is closed, we may lead the user to create the project or not.

Summary of new Workspaces
essentially, a consortium workspace is very similar to project workspace. Same is true for Working Group.

A consortium workspace consists of the followings:

the components similar to those as in the project workspace

 * what's new: follow same pattern as in "what's new" in projects and tasks
 * overview:
 * [TBD] members: [GL don't know about this: consortium participants who are also awob registered users.] In awob project workspace, this is 'collaborators'. These members are AWOB Users that have been invited to the consortium. Will generally also be "consortium participants" (see below), but need to check with scientists whether this should be enforced by AWOB or whether it is left up to the owners/managers of the consortium to do so.
 * discussions
 * calendar/meetings
 * resources

components which are new to the consortium workspace or different from those in the project workspace

 * participants: the full list of consortium participants regardless of him/her being an awob registered user or not. I.e. these people are official members of the consortium, even though not all of them may also have AWOB account.   name (first/last), email, institute, title(eg., PI, Project Scientist, etc) is given. Gives rise to mailing list separate from members mailing list.
 * [TBD] whether to support participant list AND members: need to talk to scientists.
 * --Jkim 17:22, 11 September 2012 (CEST) Onlyu support members list. Same apply to working group participant list. Just discussed with Andrea. No need to maintain two separate lists in AWOB.  It is agreed that in order to access the consortium publication archive a consortium participant must create an awob account. What concerns him is that even if invitations to the consortium are sent to all consortium participants some will not create an account. So the member list will be likely the subset of the full list. He asks whether it would be possible for consortium lead to create awob accounts for all of them and provides an option for them to change passwords. However, as Gerard points out there is no good way to find that some of them already have an awob account.
 * [TBD] MAY have pointer from here to a registered user, but this can in general not be automated.
 * --Jkim 17:22, 11 September 2012 (CEST) Not required. so removed.
 * working groups:
 * managed projects: this is the list of all the projects that have been created in context of consortium. Often first created for a working group, then at some point(eg., 'approved' by working group lead/manager) "promoted" to consortium level. New project states "pending/in progress/...." can be supported. Consortium members are given some insight in what project will be about and can send message (outside awob) to responsible person (often working group lead) whether they can participate in the project.
 * publication archive: an archive with finished publications. Some of these may have been created in context of an awob project, Some may not.
 * This archive "only" needs to support uploading publications (say as PDF), and adding appropriate metadata (MPDL should know quite a lot about this!). No life cycle support required. That is what Projects are for.

new functionalities for consortium

 * support to create project from consortium
 * invite consortium members
 * upload consortium participant list
 * or send invitations using consortium mailing list.
 * view working group list
 * view/add/remove members in/to/from consortium participants [ also remove them as participants on all working groups!]
 * view/add/remove members in/to/from consortium members [also then remove them as members of all working groups !]
 * view/add publications(eg., pdf files) to publication archive

A working group workspace consists of the followings:

the components similar to those as in the project workspace

 * what's new: follow same pattern as in "what's new" in projects and tasks
 * overview:
 * members: In awob project workspace, this is 'collaborators'.
 * These members are AWOB Users that have requested to be a member of the working group.
 * Will generally also be "consortium participants" (see below), but need to check with scientists whether this should be enforced by AWOB or whether it is left up to the owners/managers of the consortium to do so.
 * discussions
 * calendar/meetings
 * resources

new functionalities for working group

 * create working group in a consortium
 * view/add/remove members in/to/from working group participants list
 * view/add/remove members in/to/from working group members list
 * create a project for a working group ([TBD]will create actual project and add all(?) working group members as having guest privileges to it.
 * Need to discuss these new levels of privileges. Need not add all WG members as project members, more something like the way tasks can be seen by project members.)
 * promote project up to consortium level. Giving visibility of part of project to consortium members.
 * Working group leads/managers can invite consortium members (ONLY consortium members) to participate in the working group, similar to how project members are invited.
 * Consortium members (only) can request to become members on a working group. WG lead/manager can accept/decline request.

The new roles introduced to support the consortium/working group
---Jkim 12:09, 13 November 2012 (CET) a consortium lead or a consortium manager grants 'consortium member' role to any one in a consortium who needs to get a approval to proceed with a project. a consortium lead or a consortium manager grants 'consortium project manager' role to any one in a consortium who doesn't need to get a approval to proceed with a project.
 * Depending on consortium policy, managing projects in consortium can be very formal (see eROSITA) or very informal and something in-between. Some consortia require a project to be "approved" by a working group chair or steering committee in order to proceed, some don't. In some, only a consortium manager can create a project in consortium. Whatever the policy is in general ongoing projects have to be announced to the whole consortium to inform them about this and possibly avoid overlapping projects, or allow groups to join forces.
 * In order to support both requirements, introduce a role in consortium called consortium project manager.
 * Compared to a consoritum member a consortium project manager can create a project in a consortium to which she/he belongs.
 * i.e., can promote his/her project to 'consortium managed projects'.
 * therefore, a consortium lead or consortium manager should grant this role to whichever member doesn't need to seek an approval of project. or if a consortium policy doesn't require such an approval any consortium members in such a consortium can at least have a 'consortium project manager' role.
 * if a consortium policy requires an approval of project to proceed by authorized members a consortium lead or consortium manager should grant consortium member role to those who needs such an approval. --Natasa 11:28, 13 November 2012 (CET)is here meant "consortium project manager"?
 * compared to a consortium manager she/he can neither invite members to a consortium nor consortium overview.


 * Consortium lead
 * add working groups to consortium.
 * invite/edit consortium members to consortium.
 * add a managed project to consortium(i.e., consortium managed projects).
 * Upload to publication archive to consortium publication archive page.
 * Add an event to consortium calendar.
 * Add discussion to consortium discussion.
 * upload or download resources to consortium resources.
 * edit consortium overview/metadata from consortium overview page.


 * Consortium manager
 * invite/edit consortium members to consortium.
 * add a managed project to consortium(i.e., consortium managed projects).
 * Upload to publication archive to consortium publication archive page.
 * Add an event to consortium calendar.
 * Add discussion to consortium discussion.
 * upload or download resources to consortium resources.
 * edit consortium overview/metadata from consortium overview page.


 * Consortium project manager
 * add a managed project to consortium(i.e., consortium managed projects).
 * Upload to publication archive to consortium publication archive page.
 * Add an event to consortium calendar.
 * Add discussion to consortium discussion.
 * upload or download resources to consortium resources.


 * Consortium member
 * Add an event to consortium calendar.
 * Add discussion to consortium discussion.
 * upload or download resources to consortium resources.

--Natasa 11:28, 13 November 2012 (CET)Questions&Comments:
 * Task description http://colab.mpdl.mpg.de/mediawiki/AWOB_Task_030 gives an impression that any consortium member can upload publications to the consortium publication archive. This was also understood from previous discussions. Would this still be the case or only consortium project manager(s) could add publications to the consortium publication archive (in addition to consortium lead/managers)
 * --Jkim 14:54, 13 November 2012 (CET) On AWOB_Task_030 i wrote an idea i had in mind. The answer to your question is Yes. only a consortium lead, consortium project manager, and consortium project manager can upload publications to its publication archive. For the spec for 0.7 please see http://colab.mpdl.mpg.de/mediawiki/UC_AWOB_CM_06_R0.7_Manage_Consortium_Publication_Archive.


 * if only consortium project managers in addition to standard lead/manager roles can upload publications - then it is not clear do they have to do it within their projects or they can upload publications even if they do not have projects they manage at all?
 * --Jkim 14:54, 13 November 2012 (CET) Please see http://colab.mpdl.mpg.de/mediawiki/UC_AWOB_CM_06_R0.7_Manage_Consortium_Publication_Archive.
 * There are already some papers published in journals produced by consortium members.(eg., eRosita case). In such a case no awob project is associated. Also some papers published in journals could be written by people who are not a consortium member but used its publicly available data. in that case also there is no awob project to link to the publication.
 * Once a consortium is in AWOB, usually in each consortium project there is at least one of consortium lead/consortitum manager who supervies and they are the project lead. therefore, in such case, it is possible to link to an AWOB project.
 * why not any regular consortium member has a right to upload publications?
 * As is project, it really depends on consortium policy. . If in the future it is always the case that any consortium member can upload publications we’ll change it accordingly.


 * why not any regular consortium member has a right to create a project? (in any case there is a kind of project workflow - i.e. whether project is announced to the consortium or not - so this could simplify a lot the handling)
 * --Jkim 14:54, 13 November 2012 (CET) Depending on consortium, in some only a consortium manager can create a project in a consortium(eg., L-Galaxy).


 * working group lead
 * working group manager
 * working group member

New component/function on Project : request for participation
The following is speculation:

Now that some Projects can be partially open to a larger group of users (working group, consortium) we should start supporting requests for participation.:[TBD] That is, a non-project member can make a request to participate. The requests show up on the project's "collaborators" page. Possibly visible to all project members [TBD]. A project manager/lead can accept/decline the request.

Use Scenario
To support the life cycle of a consortium project AWOB should be able to support the following scenarios.

A. Set up Consortium in AWOB

 * A PI of a consortium or whoever is authorized (eg., Project scientist, Project admin) creates an consortium in AWOB by providing few information eg, name(or acronym).
 * For each consortium, the following should be available:
 * Consortium name, title
 * description and goal
 * List of WGs and their leads(or chairs)
 * List of the members including each member's institute, identify PI, consortium managers
 * science roles vs awob system roles
 * List of the projects(aggregated list of projects from all WGs.
 * Publication archive
 * There could be more than one PI for a consortium. see Planck.
 * Consortium Lead must be able to access all WGs.


 * --Natasa 10:52, 31 July 2012 (CEST)This is quite a big set of tasks already during creation of the consortium, we probably need to simplify thes such as:

...
 * create a consortium (title, description, goal) (system creates workspace, publication archive and all other neccessary components)
 * add/invite member (add them directly or invite them, by institute?)
 * create WG
 * create Project

--Jkim 16:01, 28 August 2012 (CEST) I just listed a few components that a consortium should contain.

B. Set up WGs

 * The PI or whoever is authorized creates WGs in AWOB.
 * If PI create WGs, PI becomes their WG lead. PI assigns WG chairs(WG managers).
 * If each WG chair creates his/her own WG, WG chair becomes WG lead, but must give PI a WG manager role.
 * essentially WG manager will have the same access rights as WG lead, except eg., deleting a WG
 * For each WG in AWOB, the following should be available
 * WG name, title
 * description and goal
 * the list of members, and identify its chair(or lead)
 * the list of the projects


 * --Natasa 10:55, 31 July 2012 (CEST) Questions:


 * WG members are explicitely assigned or they may be invited by the WG lead?
 * --Jkim 16:03, 28 August 2012 (CEST) Invited by the WG lead/manager.
 * can an external member, not part of a consortium be invited to become a WG member, thus also a consortium member?
 * --Jkim 16:02, 28 August 2012 (CEST) No

C. Assign WG chairs

 * The PI or whoever is authorized assigns WG chairs to each WG by some interface.
 * Alternatively, specify in invititing WG chairs to the consortiumn (see below), and once the invitation is accepted the system automatically assignes the chair.
 * [JK] For this option, 'invite to role' list should include 'WG manager' as well as 'consortium manager'. This is not so desirable since it mixes up roles in different context, eg., consortium, and wg

D. Invite members to consortium
Depending on whether the consortium created in AWOB is completely/fairly new or well established this scenario might be different.

for a new consortium

 * There may/may not WGs already defined in AWOB.
 * The PI or whoever is authorized invite some members to the consortium with the following information:
 * invitation text including scientific role they play, etc.
 * proposed AWOB consortium role (TBD).
 * Those accepted the invitation are added to consortium mailing list.
 * cf) Those invited in this stage will be very active in the consortium and could have managerial roles in the consortium eg., project scientists, WG chairs.

for a well establithed consortium
Assume that there are several consortium mailing lists for all or subset of the members. In this case, it is possbile to have several different scenarios: The PI or whoever is authorized invite as follows:


 * Use the existing consortium mailing list to send invitation globally:
 * Send an invitatio email to the consortium mailing list with default AWOB consortium role to all the members.
 * Provide options to choose which WGs each member to join.
 * Update the awob role for each member once members create awob accounts and accepted the invitation.


 * Invite top-down cascading style:
 * Send invitations only to the WG chairs mailing list with default awob role for WG chairs(eg., consortium manager TBD).
 * Once WG chairs accept invitations, consortium lead assigns chairs to each WG.
 * Each WG chair sends invitations to each WG mailing list specifying default awob consortiumn(or WG) role(TBD).
 * Change the awob role for individual member as needed.
 * Add a new WG member to consortium mailing list if not in the list, yet.
 * [AM] Consider an option to migrate all the consortium members to awob system.(Preferred)
 * --Natasa 11:01, 31 July 2012 (CEST) would also go with this option, as soon as we have sufficient information. However, if a well established consortium need to be migrated to AWOB, then we would have to have 1-2 persons from the consortium to work with and help them populating the data where needed i.e. work groups, projects, publications etc.

Invite or Request to join a consortium project using AWOB (first implemntation)
Interested consortium members do the following:
 * send an email or awob message requesting to join the project.
 * The project(lead) accepts/declines the request. For an accepted request send an awob invitation to the applicant. For a declined request send an email(and message) to notify the decision.
 * cf) in the long run provide a better interface to request to join the project via awob, i.e., send request to the project lead(or whoever responsible) to join it, and the project(lead) decides whether to accept or to decline and notice the applicants via awob.


 * --Natasa 11:03, 31 July 2012 (CEST) see comments above, for an accepted request there is no need to send an awob invitation, the sender shall become member of the project as soon as the project lead accepts the request.

Publications and metadata

 * see Publication metadata profile used in PubMan

expected metadata describing publication in consortium publication archive

 * title
 * title in PubMan
 * authors: also identify the contact
 * creator in PubMan
 * abstract
 * abstract in PubMan
 * publication type:journal, conference proceedings, conference presentation, white paper, Ph.D. dissertation/thesis, etc.
 * publication type in PubMan but the enumeration list would be a subset of those defined for PubMan.
 * status: approved[TBD], draft(open for comment), submitted, accepted
 * I haven't found an attribute from the PubMan meta data corresponding to this.
 * dates: system generated timestamp for each status change except for submitted, and accepted.
 * I have found several types of dates from PubMan metadata, e.g., created, modified, data submitted, data accepted.
 * instead of having explicit attributes would be better to store date time for status channges and uploading of different versions.
 * for submitted and accepted it's possible either
 * let a user enter the corresponding date via awob interface or
 * do it consistently, i.e, let a user change the status via awob interface and the system stores the update timestamp.
 * related project: the link to the AWOB project which produced the publication
 * estimate duration: this could be part of project metadata. However, for a standalone project and this metadata is not necessary.
 * version: TBD
 * working group: if a project which led to publication is proposed and accepted within a specific working group
 * publisher[TBD]
 * publisher ID:Bibcode, arXiv code if exists

To support the above scenario what AWOB must support

 * Set up Consortium (see above)
 * Set up WGs.(see above)
 * Add more roles.
 * on Consortium level
 * consortium lead, manager, consortium project manager, member
 * Project Admin.(or consortium admin)
 * If a PI creates it in AWOB the PI becomes the consortium lead otherwise, there should be a way to specify the proper consortium lead.
 * on WG level
 * WG lead, manager, member
 * External Collaborator, guest, etc
 * Able to change AWOB roles (in particular for case A above).
 * Support project public page. Or Give permission to the consortium members to access selected awob project components eg., overview, ePublication, collaborators, some discussion.[GL] I like latter. That will also make it more easy to support opening (part of) Project to all AWOB users. That could use same mechanism.
 * Project status, and store status change dates and other important dates
 * Support publication (archive) for both created within and external to awob.
 * Those created w/ awob: link to awob project from publication, support publication lifecycle
 * Those not created external to awob: support to upload pdf.
 * Within a WG support discussions about projects.
 * close project.
 * Ready in 6 months.