NOTE: This file contains only the major outcomes from the SSC Workshop discussions and is not really a complete set of minutes. Those wishing a more complete overview of the information presented are requested to look at the individual presentations and are also attached to the agenda. Types of SSCs ------------- During the presentations of the proposed SSCs, two types of SSCs were identified. One type serves a particular scientific user community and is largely independent of other SSCs. These have been called "vertical" or "scientific" SSCs. The other type provides a generic service to the full EGI user community and the full range of SSCs. These have been called "horizontal" or "generic support" SSCs. These may need different contact points within the EGI infrastructure. For the proposal and for the EGI organization, better names for these types of SSCs must be developed. Formation of SSCs ----------------- User communities may wish to form SSCs to take advantage of direct representation in EGI management structures and of services provided to aid SSCs. Most of the initial SSCs are expected to come from user communities in existing projects; however, EGI must be open to all requests to form SSC regardless of the community's origin. To ensure a level playing field for all user communities, EGI must provide and publicize the criteria to recognize an SSC. These criteria must be available well in advance of the FP7 infrastructure calls, so that anyone proposing an SSC will be aware of the requirements for official recognition by EGI. Presumably, EGI will also use the SSC criteria for issuing letters of support for projects related to SSCs. The workshop participants collectively developed a list of SSC criteria that should be used by EGI as a baseline checklist (see below). Once the EGI council is formed, it should discuss the criteria, amend them as necessary, and published the approved criteria. EGI must also develop a procedure for evaluating SSC proposals. An SSC must: * Have a mechanism for additional partners and users to join. * Be governed by the user community/stakeholders. * Have a European-level existence and must demonstrate the added value of a European-level coordination. Note that some of the stakeholders could be outside of Europe, but there must be a strong European component to the SSC. * Demonstrate how the SSC will advance the aims of EGI. * Have a plan on how EGI resources will be used and/or provided by the SSC's stakeholders. * Provide a sustainability plan/roadmap. * Demonstrate its legitimacy for representing a given sector of the full EGI user community. This may include letters of support from major stakeholders, explicit financial or material support, contacts with ESFRI projects, etc. It is extremely important that conflicting SSC proposals for a given user community do not arise. * Have a clear work plan and roadmap with measurable milestones. * Accept the global EGI policies. * Commit to name people to fill relevant EGI/SSC contact points. (Those people must participate at an appropriate level in the associated groups.) There are a set of associated responsibilities for EGI. EGI (probably EGI.org) must: * Provide and publish the above requirements for SSCs (amended as necessary). It must also establish a procedure for evaluating SSC proposals. * Must provide and publish the aims of the project. * Must publish the expected contact points for SSCs and the responsibilities associated with those posts. * Must publish the its global policies. The previously collected SSC guidelines should be updated to include the above criteria and to expand on how each of the above requirements can be met. Roadmap and Milestones ---------------------- Given that the FP7 infrastructure call will probably close in November and that it will only open in June, the time is extremely short for preparing proposals for the SSCs. The following roadmap was developed at the end of the workshop to ensure that we can prepare, evaluate, and improve the proposals before the call closes. The roadmap should be publicized as widely as possible to ensure that all user communities can participate in the meetings for the preparation of the SSCs. * (11 May) Provide SSC Workshop summary and actions. (C. Loomis) * (11 May) Request NGI contact points from EGI_DS. (C. Loomis) * (11 May) Provide link to FP7 proposals page and to the June 18 informational meeting. (C. Loomis) * (11 May) Propose a session at EGEE'09 to discuss the SSCs and other EGI-related proposals. (C. Loomis) * (20 May) Editorial board coordinators meet to develop initial outline of EGI-related proposals. (C. Loomis, S. Newhouse, L. Perini) * (22 May) Provide an outline of the EGI-related proposals for the SSCs. (C. Loomis, S. Newhouse, L. Perini) * (25 May) Discuss with EC representatives the plans for SSC proposals and what instruments should be used. Provide feedback to workshop participants. (C. Loomis) * (1 July) Have a follow-up meeting in Paris (Orsay) to discuss progress and the details of the call. Invite EC representatives to this meeting. (C. Loomis) * (30 June) SSCs should provide draft work plan before meeting in Paris. * (15 Sept.) Provide "final" complete drafts of SSC proposals before EGEE'09. * (~20 Sept.) Session at EGEE'09 to discuss "final" SSC and other EGI-related proposals. * (3 Nov.) Final meeting at CERN to adjust/refine proposals for submission. SSC Proposals in the FP7 Infrastructure Call -------------------------------------------- The FP7 Infrastructure Call is expected to open in June and close in November. It is expected that this call will actually be three calls: one for the core EGI proposal, one for user communities, and one for middleware. The text of the call may further subdivide the call into sections with smaller scopes. At the very least there will be three EGI-related proposals covering the key areas: operations, middleware, and user communities. In reality the middleware will consist of several proposals (gLite, ARC, and Unicore). For the user communities, there was quite a bit of discussion on whether it would be better to have a single proposal covering all SSCs, individual proposals for SSCs, or some grouping of SSC proposals. The following list contains the various advantages (+) and disadvantages (-) for multiple proposals (M) or a single proposal (S) that were mentioned during the discussion. M- : Multiple proposals increase the overall administrative overhead as each SSC must then deal with the burdens of formal interaction with the EC (financial, reviews, etc.). M- : Following a strict one SSC => one EC proposal may eliminate some viable SSCs simply because they can not find an appropriate lead partner to handle financial/administrative details or because the group lacks the expertise in dealing with EC proposals. S+ : Easier to identify and exploit synergies between SSC within a single project. S+ : Because of the synergies (at the scientific and administrative levels) there will be an overall lower requirement for manpower. M+ : Separate proposals would give each SSC a strong, independent voice in its interactions with EGI. M+ : Separate proposals mean that the evaluation of SSCs will be done independently of each other. (This may be good for "strong" SSCs and bad for "weak" SSCs.) M+ : Separate proposals would put the burden of determining the quality of each SSC on the EC review process. There wouldn't be the need for "internal" vetting of SSCs as in a single proposal. M+ : Separate proposals would put "internal" and "external" SSCs on equal footing. (I.e. SSCs proposed by people we don't know about would not be disadvantaged by not being part of a combined proposal.) S+ : A single proposal would allow EGI as a whole easily to project a common message and coherent structure. S- : The lead partner for a combined proposal would have significantly more work to do to coordinate the financial and administrative details. S+ : One proposal may be more flexible in terms of adapting to unforeseen changes. S- : One proposal may give the impression that EGI is just EGEE-IV and may cause groups outside of the EGEE sphere to ignore efforts to coordinate SSC activities. S+ : One proposal would allow us to maintain the current momentum. S+ : A single proposal may make the transition easier between EGEE and EGI. S+ : A single 'horizontal' SSC would be fairly easy to do. S- : A single proposal is a high-risk strategy with the possibility to have all SSCs rejected. S+ : A single proposal could allow funding for 'SSCs in incubation'. Possibly making it easier to expand the user community. M- : Separate proposals for horizontal and vertical SSCs may make it difficult to coordinate between them. S- : May have a problem with demonstrating legitimacy for all of the enclosed SSCs in a single proposal. This may just continue the "HEP domination" of the funding and influence. M- : Must have multiple lead partners for separate proposals. The workshop participant agreed that the work on the proposals must be done in as modular way as possible to adapt the work easily to the text of the call in June and to the expectations (multiple/combined proposals) of the EC. In any case, the various SSC proponents were asked their current preferences for separate or combined proposals. The "horizonal" SSCs believe that they could combine their efforts into a single proposal. Discussions between those SSCs have already started at the workshop and they will work in that direction, waiting for further information to become available. The "vertical" SSCs had the following preferences: Fusion: Will submit a separate proposal. Earth Sciences (ES): Prefer a single proposal but will join with AA if separate proposals are prepared. Astronomy & Astrophysics (AA): Prefers a single proposal but will join with ES if separate proposals are prepared. Life Sciences (LS): Prefer a single proposal. Grid Observatory (GO): Strongly prefers a single proposal. High Energy Physics (HEP) => Prefers single proposal. Computational Chemistry & Material Science (CC) => Prefers a single proposal. This information should be discussed with the EC to see whether they prefer to have SSCs combined into a few proposals (or single proposal) or to have many SSC proposals.