1. Present: Daryl Swade, Megan Donahue, Mauro Giavalisco, Howard Bushouse, 
   Gerhard Meurer, Anton Koekemoer, Bill Sparks, Dorothy Fraquelli, Tony Keyes,
   Jerry Kriss.

2. Drafts of current implementation studies are attached to this message.
   They include:

	fraquelli_quality.121901
	bushouse_custom.121801
	gaffney_custom.121801
	keokemoer_wcs.121701
	dickinson_photoz.121701
	sparks_imcomb.121701
	donahue_catalogs.112801
	meurer_catalogs.112801

3. Discussion of GUI interfaces.  These will be needed for all the tasks we
   are considering, so this is a common development effort.  Can be based to
   some extent on current OTFR, StarView, and APT screens.  There should be some
   effort to preserve the same "look and feel".  A problem is how do we handle
   complex selection of parameters in such implementations as customized
   reprocessing? (See Niall Gaffney's comments in gaffney_custom.121801.)
	- One option is to "hide" complex options in pull down menus.
	- Hiding is easy. The problem is design and development.
	- Nothing yet handles parameter files
	- Also, if an interface is too complex, no one will use it.
	- Option: have users submit a command script to MAST for validation,
	  and then run it?
	  This isn't a lot different from users doing their own processing,
	  except that they use our computers and our disks ...

4. Discussion of where do we draw the line in user flexibility?
   - If we provide unlimited choices and flexibility, there is little
     value added.
   - A criterion used in our original rankings was that value added by STScI
     expertise or special capabilities was important.  Therefore, in cases that
     make sense, we should use our expertise to arrive at optimal solutions
     and make user choices fairly limited.  The highest priority implementations
     will be ones where the solutions are well defined and deliver a robust,
     trustworthy product.
   - In the specific case of image combination, a reasonable place to draw the
     line is in combining data sets that were obtained with the intention of
     being combined in a mosaic.
   - Complication: not all data sets intended to combine in this way have
     Phase II proposals written so that the data appear in the same association.
   - Need some flexibility in allowing users to decide what belongs in an
     association.  Have a screen that presents data sets to be marked for
     inclusion in a way analogous to how they are marked for retrieval from
     the archive?

5. Discussed updating keywords and the archive catalog based on the results of
   an OTFR request.
   - problem in that this is non-uniform if done only on request.
   - systematic reprocessing of entire data sets is an enormous task.
     (Minutes to process a WFPC2 image, 85k - 100k images, ...)
   - While a big task, systematic reprocessing may be a good idea for the
     end-of-life closeout for an instrument.  ECF did this for FOS blue side.
     This may be a good thing for STScI/ECF/CADC to undertake for other
     instruments at end of life.

6. Where do PDF (paper) products fit in the scheme?  They currently aren't
   saved indefinitely. Regenerating them requires reprocessing since they use
   calibrated data.  Generation in an OTFR request will be made an option in
   StarView.  Would be nice to store them, or at least to store GIF images.
   Problems in generating previews of proprietary data:
   - Technical: need to keep such entries in the archive catalog proprietary
   - Political: this would disenfranchise CADC, who makes preview images for
     us after data go proprietary.

7. Megan asks how long is the testing/release process for something new added
   to the pipeline?
   - At a minimum, need to run through the OPUS test and build cycle, which
     can take several months.
   - If changes to IRAF/STSDAS are also involved, additional testing time there.
   - Process to go from prototype scripts/code to robust pipeline code can
     take quite a while, depending on resource availability.

8. Tasks and schedule to converge to a final SHARE report:

	* Finish, distribute, read the implementation plans.

	* Discuss these at another meeting.  Assess whether any of our
	  priorities have changed.

	* Think about timelines/roadmaps for implementation.
	  Lay out a draft plan and discuss at another meeting.

	* Produce/review/submit final report.


*****   Next meeting is likely to be week after AAS; shoot for Jan. 16.  *****