On the Meeting with the Registrar

Notes from the meeting // Issues the meeting brought up


Notes from the meeting

Here is a general summary of my notes and observations from the meeting with David Wiley, MIT's registrar. Before you read on, I would like to include the following disclaimers:

-Jonathan Litt




1) You can read some of the actual institute policies on the MIT Policies techinfo page. One useful one in particular is the "The Privacy of Student Records" policy page. Note that these policies are dated 1990 and may be slightly out of date.

2) Check out transaction number 102 on the 6.033 discuss meeting for some more information about submitting grades.

3) Most people were pretty confused whenever Mr. Wiley mentioned the "secure network." To the best of my knowledge (no guarantees here), the secure network consists of: a few IBM 3090 mainframes kept down in W91, and connections to these mainframes via MIT's internal phone system. I think that in order to connect to the mainframe, you need to plug your computer into the serial port on the back of those black AT&T ISDN phones. There may be other additional requirements (e.g., someone has to turn on your connection in a phone closet somewhere.) Of course, you also need a valid account and password. Either way, the general idea is that this all happens over MIT's internal phone network, and not MITnet, which is a broadcast packet network and a lot easier to abuse in terms of spying on traffic and breaking into machines.

4) Check out the 6.033 discuss meeting for some transactions that were posted about SIS.


Issues the meeting brought up

Some of the registrar's comments brought up some issues about the design project and added constraints to the problem we gave you. Here is one set of responses to those issues--one view of how to reconcile the registrar's opinions with the design project's goals. You should treat our responses as additional food for thought.

You should remember that the registrar is only one of the system's users, and has one particular view of what it should do. This doesn't mean that the registrar's view or needs will equal students' views or needs, or departments', or faculty's. This design project is turning out to be very realistic: the users may not know exactly what they want, and different users may have conflicting needs. You will encounter this many more times in your lives!

  1. We are asked to "think through the processes behind the forms. Maybe you can simplify several forms into one...."

    However, the registrar cannot necessarily simplify the forms. The signatures required on each form, and the content of the forms in general, are mandated by faculty rules. The registrar only implement these rules.

    Response: You should make recommendations to the faculty concerning what forms should be changed and how, but be flexible enough to handle whatever decision they make.
  2. State law (might actually be national law) mandates that a request for a transcript be physically signed by the student.
    1. The electronic request you implement might not be binding, but a "hint" for the registrar to start processing the transcript, much like fax requests-for-transcripts are now. (When a fax request is received, the registrar starts processing the form, but waits for actual written and signed notification before sending.)
    2. You could design a protocol secure enough to act as a legal test case for digital signatures!

      (For your browsing pleasure, here is a set of pages on Utah's Digital Signature Law. Do not worry about legal issues such as this law when doing your design project! This link is mostly for fun.)

  3. The registrar is very happy with the back-end system in place now, and cannot think of anything that needs changing. (The back-end system is the mainframes currently handling the databases and forms.) Can't we just use the existing back end?
    1. It is not sufficient to simply say that you will use the registrar's existing computer system as a back end to your design. If you do use the existing system, you must convince your audience that the existing system will meet all proposed and future needs, and has no holes. Think about scalability (if enrollment quintuples or more), security (the current system is not directly connected to MITnet; yours may have to be), etc.

      If you do use the registrar's system, we don't expect you to understand it from the inside out. One way to meet our expectations would be to give a large set of explicit assumptions about how the current back end might work, and work only from those assumptions when creating the rest of your design. (Note that, if these assumptions are detailed enough, you will have essentially redesigned the back end!)

    2. It is not surprising he is happy with what the Registrar's Office built themselves: they know it, they control it, etc. However, this does not mean that the registrar's view coincides with the rest of the users of the system! They might agree, or not.
  4. When someone brought up Issue 13,
    How will you make sure that your system continues to work, with minimal changes, when major Institute policy shifts (like intermediate grades, class-specific drop dates, or advisor-specific add and drop policies) are implemented?
    Mr. Wiley laughed out loud. "Class-specific drop dates? Advisor-specific add or drop policies? That would be a nightmare! The faculty would never go for that."
    1. We have subject-specific add dates now: you can add or reduce units for your thesis or UROP right up to the day that the grade is submitted.
    2. It might be easier to point to history than to second-guess the future. Over the last thirty-five years we added Freshman Pass/Fail, junior-senior Pass/Fail electives, and January IAP. The general Institute requirements have switched from counting hours to counting subjects. The science distribution requirement has gotten more complicated. Institute Laboratories were added. The humanities program has added concentration/distribution requirements. The writing program was added.

      Your system will have to be flexible enough to handle more changes like these: it would be foolish to assume that, after thirty-five years of often sweeping change, we have found the Right Way and will never make substantial changes again.

    3. Finally, it is interesting to note that Marty Schlecht, head of the FAST team and a faculty member, sees advisor- or class-specific add and drop dates as a selling point for the faculty on the new system! Again, remember that the registrar has only one view.

Top // 6.033 home // Probably last updated 4/27/96