Re: [saga-rg] Research Group / Working Groups
To: Tom Goodale
Hi,
We discussed the research group/working group structure on today's call, present were myself, Andre, Shantenu, Thilo, Pascal and Hartmut.
The consensus was to go down the umbrella research group with spawned working group road.
To be concrete:
We propose to split the current RG in two:
SAGA-RG:
This research group will be responsible for deciding look and feel of the API, identifying new SAGA subsystems which we should/might want to have APIs for, spawning working groups to look into them (e.g. after a design team has come up with a straw-man), and coordinating the resulting working groups. It could look into issues with OGSA alignment, or work with OGSA to spawn a group to look into common issues.
This group will inherit the current charter, but remove the API document deliverables and add some text describing the new scope, the process for spawning working groups, and the relationship between the RG and the groups.
Proposed chairs: Tom Goodale, Shantenu Jha, Thilo Kielmann
SAGA-CORE-WG
This group will concentrate on producing an API document from the current strawman. It will inherit the current charter, but removing the use case and requirements document deliverables. The charter will be refined to specify precisely the areas covered by the strawman as the scope of the WG, and will define how it relates to the RG. The timeline for producing the API documents will be unchanged.
Proposed chairs: Tom Goodale, Andre Merzky
Note that the chairs proposed above are just suggestions, and will need to be ratified by the group. If anyone else would like to become a chair, or if anyone has an issue with the proposed chairs, please don't hesitate to speak.
This reorganisation will hopefully produce a clear delineation of the roles of the research group and the working group, and provide a mechanism for us to spawn more working groups to look at other subsystems such as GridCPR and GridRPC, or start SAGA activities within such groups if that would be appropriate. Creating new WGs in this way would, we hope, make it easier for people to engage in the process of defining new APIs, and provide a much clearer process for the generation of these APIs.
We do have some worries, though, which we need to discuss before finalising on this route:
1) Will the additional admin overhead be worth the gain ?
The feeling on the call was that this approach has potential to get more people involved, and worst case, leaves us in the current situation with an active WG and an inactive RG.
2) Will this approach really help us to engage and attract new people ?
We are hoping that the ability to spawn small, tightly-focussed groups will help make it easier to attract people and focus them on the API development.
We are planning to have another conference call next Wednesday at 1400 GMT (same time as today's call), to continue discussion of this, and on Thursday wish to send the decision of the group to the GFSG so that they may discuss it before GGF.
I know this is a short time-frame, but we need to finalise this issue soon, and comments from the wider group are essential. Please speak up one way or another in the next few days as to whether we should go forward with this plan, or ask the GFSG to just 'flip-the-bit' as per the original discussions. Any other comments or suggestions would be great.
Even a response such as 'no, just flip the bit', or 'go for it' would be helpful.
We have assurance from the ADs that whichever way we decide to go, the transition will be quick and relatively painless.
Cheers,
Tom
Hi Craig, many thanks for your comments, and I think you hit the main point right on target: all calls for an Umbrella RG will be in vain if we don't manage to engage more people from within GGF, with a broader background than we have in the SAGA-RG right now. Tom suggested basically the same during our call as you do: in the worst case, if nobody brings it to life, the RG is a very quiet, idle one. Its probably our task to create a certain amount of understanding and enthusiasm for the SAGA approach to get it really flying. This will probably not happen immediately, but over time. Well, on a second though: GridRPC folx are the _perfect_ crowd to take the lead on active participation in the SAGA-RG *hint! hint!* ;-) Cheers, Andre. Quoting [Shantenu Jha] (Feb 04 2006):
All,
I apologize for not making today's telecon but I was very happily trying to get some real work done by not talking on the telephone or responding to email (until now ;-).
I think the proposed decision here is the best approach!
I do, however, want to give my 2 cents on how I think things should work out in reality. (Steven and Dieter: Are you listening? ;-)
The umbrella RG is a strategic move for all of GGF (not just for SAGA or the GFSG debating society!) The ability to coordinate the look-and-feel of grid APIs will be, imho, quite beneficial.
Given the reality of the available cycles, however, the core SAGA team should get their bit flipped so they can charge full-speed into the WG work.
The RG can be relatively inactive and just kept "on the books" as we (the GFSG and SAGA team) "socialize" the idea of coordinating APIs across GGF with other WGs. Of course, by "socializing" the idea I mean getting people to understand its importance and become part of a self-sustaining critical mass to do the work (like the SAGA team has now).
This should definitely be a discussion topic for the Town Hall meeting.
My best regards to all,
--Craig
At 04:27 PM 2/3/2006, Tom Goodale wrote:
Hi,
We discussed the research group/working group structure on today's call, present were myself, Andre, Shantenu, Thilo, Pascal and Hartmut.
The consensus was to go down the umbrella research group with spawned working group road.
To be concrete:
We propose to split the current RG in two:
SAGA-RG:
This research group will be responsible for deciding look and feel of the API, identifying new SAGA subsystems which we should/might want to have APIs for, spawning working groups to look into them (e.g. after a design team has come up with a straw-man), and coordinating the resulting working groups. It could look into issues with OGSA alignment, or work with OGSA to spawn a group to look into common issues.
This group will inherit the current charter, but remove the API document deliverables and add some text describing the new scope, the process for spawning working groups, and the relationship between the RG and the groups.
Proposed chairs: Tom Goodale, Shantenu Jha, Thilo Kielmann
SAGA-CORE-WG
This group will concentrate on producing an API document from the current strawman. It will inherit the current charter, but removing the use case and requirements document deliverables. The charter will be refined to specify precisely the areas covered by the strawman as the scope of the WG, and will define how it relates to the RG. The timeline for producing the API documents will be unchanged.
Proposed chairs: Tom Goodale, Andre Merzky
Note that the chairs proposed above are just suggestions, and will need to be ratified by the group. If anyone else would like to become a chair, or if anyone has an issue with the proposed chairs, please don't hesitate to speak.
This reorganisation will hopefully produce a clear delineation of the roles of the research group and the working group, and provide a mechanism for us to spawn more working groups to look at other subsystems such as GridCPR and GridRPC, or start SAGA activities within such groups if that would be appropriate. Creating new WGs in this way would, we hope, make it easier for people to engage in the process of defining new APIs, and provide a much clearer process for the generation of these APIs.
We do have some worries, though, which we need to discuss before finalising on this route:
1) Will the additional admin overhead be worth the gain ?
The feeling on the call was that this approach has potential to get more people involved, and worst case, leaves us in the current situation with an active WG and an inactive RG.
2) Will this approach really help us to engage and attract new people ?
We are hoping that the ability to spawn small, tightly-focussed groups will help make it easier to attract people and focus them on the API development.
We are planning to have another conference call next Wednesday at 1400 GMT (same time as today's call), to continue discussion of this, and on Thursday wish to send the decision of the group to the GFSG so that they may discuss it before GGF.
I know this is a short time-frame, but we need to finalise this issue soon, and comments from the wider group are essential. Please speak up one way or another in the next few days as to whether we should go forward with this plan, or ask the GFSG to just 'flip-the-bit' as per the original discussions. Any other comments or suggestions would be great.
Even a response such as 'no, just flip the bit', or 'go for it' would be helpful.
We have assurance from the ADs that whichever way we decide to go, the transition will be quick and relatively painless.
Cheers,
Tom
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
participants (2)
-
Andre Merzky
-
Shantenu Jha