<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffcc" text="#000000">
Hello *, <br>
<br>
As a member of the ESGF committee, and primary architect of the
current infrastructure, I thank you for the recommendation. At the
moment ESGF is a nascent, cooperative, open-source effort that is
currently overseen by the members of the ESGF committee. Thus, it
seems appropriate that this idea be something to address to the ESGF
committee as a whole for further discussion. The ESGF committee is
the managing level organization for ESGF and therefore we need to
ensure that the committee is fully involved in any decision process
regarding federation level activities.<br>
<br>
One thing I can suggest would be sending an email to the committee
mailing list, <a class="moz-txt-link-abbreviated" href="mailto:esgf-committee@lists.llnl.gov">esgf-committee@lists.llnl.gov</a>, and the committee will
convene and explore this suggestion more thoroughly.<br>
<br>
As stated in the original email; this will not preclude individuals
from personally using whatever mechanisms they need to maximize
their own efficiency, however, the ESGF committee has been created
to address management level decisions such as the recommendation
that has been made. <br>
<br>
As a point of information. ESG and ESGF are not the same things and
thus are not managed in the same way. ESG is the current
infrastructure that we are standing up (data nodes and gateways),
while ESGF is an open source, community-involved evolution of
technology, tools and technologists to provide the necessary future
infrastructure to support the scientific community. <br>
<br>
Thanks again.<br>
<br>
<br>
On 8/9/10 7:01 AM, Bryan Lawrence wrote:
<blockquote cite="mid:201008091501.19471.bryan.lawrence@stfc.ac.uk"
type="cite">
<pre wrap="">
Hi Folks
We also talked a fair bit about management tooling at NCAR and NOAA,
recognising that we need to do something to help manage our
collaborative efforts ...
We've discussed the general principles before, but we were discussing
the benefits of trac, jira, etc ... and while we appreciate that at the
GFDL meeting there was a desire to use trac, some issues are know with
trac - not least that it's difficult to manage multiple sub-projects from
one trac instance.
It is important to note that we are *NOT* implying that individual
groups will need to migrate to whatever we use. This is for federation
level activities, and it's likely that individual subprojects which are
already integrated into local management wont change.
The overriding criteria for whatever we used is that it has to be free
and scalable, wth open administration (remote users can administer it
easily).
Desirable characteristics included the ability to have a ticket
heirarchy, and multiple subprojects and milestones.
Sylvia and Stephan have looked into redmine, and are recommending it for
the ESGF level management.
We'll look into that in the NH autumn.
Cheers
Bryan
over and out ...
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Gavin M. Bell
Lawrence Livermore National Labs
--
"Never mistake a clear view for a short distance."
-Paul Saffo
(GPG Key - <a class="moz-txt-link-freetext" href="http://rainbow.llnl.gov/dist/keys/gavin.asc">http://rainbow.llnl.gov/dist/keys/gavin.asc</a>)
A796 CE39 9C31 68A4 52A7 1F6B 66B7 B250 21D5 6D3E
</pre>
</body>
</html>