Minutes of Meeting, May 19, 2006 1:00 CDT
Present: Rob, Suzanne, Jim, Wally,
By Phone: Claude, Janice.
Minutes written by Rob.
Corrections and comments are welcome.
[ My editorial comments in square brackets. ]
We will meet Friday May 26 at the usual time and place; most people
will be present even though that Friday is the start of the Memorial
Day weekend.
Suzanne has the project web site up and running:
http://cd-amr.fnal.gov/ilc/LogbookEvaluation/LogbookEvaluation.htm
When you have documentation to add, please add it to the
ILC demo document database. We will soon have a link on
the web page to show all documents in the docdb that are
part of our project. If you need the username and password,
or other information about the ILC demo docdb, contact Rob
or Suzanne.
If you also need a link from the project webpage to your
document, send email to Suzanne.
Over the week Janice and Elvin emailed us with the homework
they promised. Janice's is on docdb/website and Elvin's will be
soon. We all need to take a look at this.
The bulk of the meeting ended up as a discussion of "Plan for the
Logbook Evaluation Task Force" ( see link on the web site).
This draft was circulated by Rob before the meeting and is written
as a traditional software development model:
1) collect use cases
2) derive requirements
3) justify decisions by reference through the requirements back to
the use cases.
Claude suggested two things about this procedure:
1) There is probably not enough time to do a good job of starting
from first principles.
2) Because we are strongly urged to pick an existing product,
the wisest first step might be to narrow the list of candidates
based on our professional judgement about the quality
of implementation and our estimate of the cost to support the
product in the long term.
Below is my attempt to summarize the discussion that followed:
Even if we choose to follow Claude's point 2) as an intial step,
we still need to talk to end users and develop use cases:
1) If we want to recommend siginficant investment in the support of
the product, we need to have a strong case to support that
recommendation. The strongest cases have a trail going to back
to use cases.
2) A failing of many software projects is getting bogged down in the
implementation of expensive features of marginal utility. If we
have a reasonably complete set of use cases we can identify
such cases and assign them low priority. Moreover we can defend
our judgement against people who wish to assign the feature a
higher priority. Some examples:
- Do we need "one click install" on an arbitrary users laptop.
If so, this eliminates any product which requires that
Tomcat be installed on the laptop.
- Everyone wants keywords. They almost always prove to be
useless.
3) We suggested the July 1 deadline ourselves, should we ask for the
time to do this correctly?
[
I spoke with Patty McBride and she suggested that getting as much as
1 FTE to support the chosen product would be very difficult.
I think that we should structure our recommendations so that it
is possible to proceed even with this low level of support but we should
also make clear the priorities in the event that a higher level of support
does become available.
]
Other points made:
1) We can do both in parallel, develop use cases and evaluate the
underlying architecture of each product.
2) If we exclude a product based on it's architectural soundness, but
it has unique features, we can estimate the effort to add the features to
an architecurally sound product. This feature can then take its
place in the priority list.
3) There was a discussion of what constitutes "architecturally sound".
- If a candidate is written in "C", does that exclude it?
- If a candidate is does not support "central management" of
several log/note books. Does that exclude it?
- If a candidate is only proven on one platform does that exlude it.
Suzanne will collect these questions, and others, and make
a Q&A sheet for us to use to evaluate the architecural soundness of
each prodcut.
[ Suzanne has circulated the Q&A sheet by email. ]
4) We need playable demos of all candidates that pass any early cuts.
Homework:
We will speak with the authors/maintainers of the packages under
consideration and learn enough to evaluate their architecural soundness.
Use Suzanne's Q&A sheet as a reference; feel free to add to this sheet
by editting version in the docdb and submitting a new version.
The assignments are:
Claude - the old and new DESY products and weblog.
Suzanne - CRL
Wally - Elog
Janice - JLAB
Rob - PSI
We are asked to submit our findings by Wednesday so that they can be
compiled before the meeting next week.
There are minutes attached to this event.
Show them.
