Subject: Draft: Where I would like to be with Watchmakers
Date: Wed, 30 Oct 1996 11:38:11 EST
From: Mike Barker <mbarker@MIT.EDU>

[some thoughts on this business of student developers/urops...]

1.  We should have a group of students working in the zone.  That
means 12 to 16 people (4 pc, 4 mac, 4 to 8 unix).  This can be a mix
of UROP, theses, consultants, etc. but we should know who is going to
be using these systems and be planning for the next wave.

e.g. right now, we should be planning for IAP.

2.  These students need more structured projects than we (the unix
group) have been providing.  This requires some upfront time for

	plan
	design

and during the project some time for checking progress, training, and
such mentoring.

I recommend that we (the unix developers) take a few small projects
and lay out plans and designs for them.  We should review with each
other these plans and designs, making sure that they are
understandable and doable.

Then we should provoke some students into working on them.  As part of
the regular meetings, both the students and their "supervisors" should
report on progress.  We may want to have some separate meetings for
supervisors to review the plans, designs, and progress - mostly to
make sure the tools are doing the job and we are on track.

I would expect supervisors to provide (both to the students AND to the
development group):

	plan (steps plus schedule)
	design
	regular status reporting
	completion presentation/post mortem review

A critical part of this is understanding that the supervisors also are
learning how to supervise and how to present their proteges work.

3.  We need to coordinate UROP hiring with ops, network, kerberos...
to make sure we have the best students.

Administration, introductions, and so forth should be coordinated so
that we don't have "surprise" watchmakers appearing.

We need to be sure that starting salaries and raises for continuing UROPS
are handled in a sane fashion.

4.  We also need to get rid of students who are not meeting the
expected level of productivity.  We simply cannot afford to tie up the
developer's time or the student's time if this isn't working.