Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI Deliverable or milestone identifier: DNA2.1.1
Title: Collaboration Programs Doc. identifier: EMI-DNA2.1.1-CDSREF-Collaboration-Programs-v1.1
Author(s): Diana Cresti (NA2, INFN) Due date: PM1 (May 2010)

Identification of the reviewer
Name: Alberto Di Meglio Affiliation: CERN EMI Activity: NA1

Review date 11/08/2010
Author(s) revision date mm/dd/yyyy
Reviewer acceptance date mm/dd/yyyy

General comments

The current version of the document gives only limited information about the collaboration programs. It lists a number of potential collaborating partners, but lacks a more detailed description of the overall collaboration strategies, the individual collaboration programs, the communication channels and instruments and especially the expectations and long term vision. There should be less focus on individual projects and more information about the EMI aspects of establishing collaborations programs. There should also be some description of how the collaboration outcomes are monitored in order to fulfil the stated expectations. The reader should not be left with hanging questions of the type: "Ok, you will do this, and so what?"

The document is a in places a bit unbalanced towards EGEE, there is little mention of ARC and UNICORE and their existing or planned collaboration partners.

Additional recommendations (not affecting the document content, e.g. recommendation for future work)

The first instance of this series of deliverables should be a plan, while the following instances should report on the execution of the plan and the achievements, in addition to any revision or improvement on the original plan.

Detailed comments on the content

Note 1: The reviewers must list here any observation they want to track explicitly and that require interaction with the authors
Note 2: These comments have to be explicitly addressed by the authors and the action taken must be clearly described

All comments are also tracked in the document itself for easier handling.

Page Section Observations Reply Is Addressed?
1 5 1.1 The text states that a full list of collaborations will be put on the web site. Where is it? It would be better to have it in place before submitting the document and put here the actual link, also because the document also states that there are continuing collaborations inherited from previous projects    
2 5 1.2 Revise description of section 3 after we clarify in more details what the program is about    
3 6 1.4 The person allowed to amend the document should not be a generic “author”, but a precise role, like the “NA2 WP Leader” or the “Dissemination Officer”. The author may change. That’s why in my opinion a generic amendment rule referenced in all documents doesn’t work. Every deliverable has specific owners and rules.    
4 7 2 I’m not sure this Executive Summary really summarizes the document. An Exec Summary should describe in plain terms the key points of the document in the same order as they appear in the text and describe the main pre-conditions and expectations. In principle, it should allow a person to tell what’s in the document without reading it. In this case, I’m not sure I could be able to talk about the content of the doc just by reading this. The usual length of a standard ES is about 1/10 of the length of the doc, therefore you can extend it to a full page    
5 7 2 Why saying that the categorization is a matter of convenience? The categorization has a specific purpose, to create the right frameworks for different entities to work with us. There will certainly be exceptions, but this should not be just for convenience, but to clearly identify the right targets, the right communications channels and the expected outcomes for each type of collaboration    
6 8 3 I would not say "collaborations at Month 1". This is our plan and must define the collaboration strategy for the rest of the project even if it will certainly be revised and adjusted as we go. The document is not about describing the names, which can change, but rather the concepts, strategies and expectations, which should change less frequently    
7 8 3 Same as before. This is a plan. It must describe what we want to do, how we want to do it, what we plan to give and what we expect to get. It must be more that a “statement of intention”    
8 8 3 Before moving into the description of the collaboration categories, I suggest to put everything into context. You should describe what is the reason to establish collaborations, what types of targets we have identified, how the collaboration programs will be managed and monitored, etc, etc. After that, you will be able to state why we have defined the three collaboration categories and proceed to describe them in details    
9 8 3.1 I’d like to see more high-level details on what this category of collaboration is about, how it will be managed, what are the expected results, what communication channels will be used, etc. After that you can give specific examples and mention EGI and the others. For the moment, this section is a list of projects, but it doesn’t say anything about the collaboration program itself    
10 8 3.1.1 You mention "exceptions". What exceptions? If you state this, you should also make clarify what the issues are and what actions are being taken to solve them    
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2010-08-12 - AlbertoDiMeglio
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback