0. Meta question: now that longjobs has graduated to Delivery, should we
   use Owls as the body for initial consultation and feedback on policy
   issues that the longjobs team raises (i.e., for general policy
   decisions, capacity planning, funding/staff-effort recommendations)?

   (Owls agreed at the 11/19 meeting that it would be the right place,
   minutes in fuzz[1910].)

1. Should we work on adding Linux slaves now, or wait until there's an
   explicit demand?  If the latter, we would like a commitment that
   guarantees sufficient lead time (e.g., advance notice of one term,
   with management working out any necessary compromise with faculty).

   In general, should demand be considered a factor when determining
   whether support for a particular platform is "feasible"?  (In earlier
   reports/proposals, we said "If feasible, all platforms in the current
   Athena release should be represented in the slave pool.")

2. Clarify issues surrounding eligibility, both for sane user
   communication and staff workflow; identify decision path for
   eligibility and priority questions.

   - Our policies and procedures should be in synch with Cluster Patrol
     and stopit practices; in particular, if an applicant does not meet
     eligibility requirements or is turned away due to capacity
     constraints, there should be a clear communication back to the user
     (and other IS groups as needed for future reference) about whether
     they may use bldg 37 on weekends, or whether they should be using
     non-Athena resources; particularly in the Sponsored Research case,
     someone should follow through with the faculty advisor (stopit,
     ACST management?)

   - FLs will handle courses; UROP and thesis applications will go to
     Accounts, but they should not be burdened with eligibility
     determination if users doesn't fit into any of those standard
     categories.  Perhaps such inquiries should go instead to a list
     including longjobs team for technical/capacity questions, ACST mgmt
     for eligibility questions, or bump to Owls if policy discussion is
     needed?

   - We need to establish a clear policy which guides us in accepting
     registrations for the service.  For example, should registrations be
     granted simply on a first-come/first-serve basis, should we reserve a
     certain percentage of time for, say, courses (thus possibly delaying
     or denying registration to individuals), etc.

   We propose having the application form:

         A. make eligibility requirements clear up front; if we need an
	    explicit checkoff from users on the Sponsored Research
	    restriction, perhaps add something just above the submit
	    button such as "by submitting this form, you confirm that
	    you will not use longjobs for Sponsored Research"

	 B. include choices for standard academic uses only (i.e.,
            course, thesis, UROP); if use would be "other", the user
            should be directed to an email address or separate form to
            be fielded by appropriate decision makers (as decided
            above)

3. Clarify policy on supporting software not licensed to run on a
   generic Athena workstation.

   A previous incarnation of the longjobs project notebook listed among
   "What longjobs IS NOT":

     A way to run software that is not supported on Athena platforms. 

   which could be made more explicit, assuming we retain the same notion
   of scope:

     A way to run software that does not run in the Athena clusters
     (whether due to software incompatibility or license restrictions).

   Background: experience this term raised the possibility that faculty
   may want to run software that the vendor requires to be node-locked
   (e.g. that is either currently runnable only on private Athena
   machines in their dept).  Because we have dedicated execution slaves,
   it would be technically possible to run node-locked software on them,
   but this would change the generic nature of the machines, imposing an
   extra burden on Athena Server Operations (e.g., if a machine needs
   replacement, they would either have to preserve pieces of hardware
   tied to the license key's node ID, or have ACST get new keys from the
   vendor) and ACST staff (license manager configuration/troubleshooting
   and vendor liaison side).