not logged in

Frequently asked questions (updated 31 August 2021)

  • What is this site and how does it work?

    Please read the short summary on our about page.

  • Who can use this site?

    This site is open to all current MIT students and instructors via Touchstone authentication. Every MIT class listed with the registrar this term has been pre-registered with pset partners so that it can be activated by the responsible faculty member with a single click.

    You should be aware of our code of conduct. In addition to standard MIT policies, at pset partners we expect all students to be welcoming, understanding, and to reach out to new pset partners. If you cannot commit to taking these positive actions you should not use this site.

  • Why don't I see my class on pset partners?

    If you are a student, this is because your class has not been activated — please contact your instructor. If you are an instructor who is not the responsible faculty member — please contact the responsible faculty member and ask them to activate the class and add you as an instructor. If you are the responsible faculty member, please contact us.

  • Do I need to be registered for a class in order to join a pset group?

    No, we know that registrations are often in flux at the start of the term and we don't want to slow down the process of finding you pset partners. But we strongly discourage joining pset groups or the match pool in classes you are not seriously planning to take. We know that life happens and plans change, but it is not fair to your classmates to join a group you do not intend to work with. If your plans do change, be sure to explicitly remove yourself from any groups you have joined; don't ghost your group (this applies whether you are registered or not).

  • What time does the matching take place?

    The process begins at 10pm on the match date (MIT time), and usually finishes within an hour or two, but email notifications may be delayed by up to 12 hours.

  • I added a class to my profile. Why wasn't I placed in a pset group?

    To be included in the weekly matching for a class you need to join the match pool by clicking the "Match me XXX" link on the partners tab for that class. Alternatively, you may be able to join a private or public group, or you can create one using other links on the partners tab.

  • Which browsers/devices do you support?

    Our site should work resasonably well on most modern desktops, laptops and tablets. It is not designed for mobile use.

    We have tested the site on recent versions of Brave, Chrome, Chromium, Edge, Firefox, Opera, Safari, and Samsung Internet browsers running on Android, Chrome OS, iPadOS, Linux (Pop! OS and Ubuntu), MacOS, and Windows. We have not had time to test every feature on every platform, so there may be problems we have missed — please let us know if you encounter one.

    We do not support Internet Explorer (use Edge).

  • What do the "public", "automatic", "permission", and "invitation" membership options mean?

    Groups with public membership are open to all, and their membership is visible to everyone in the class. All other groups are private, meaning their membership is not visible to students outside the group, but there are different ways private groups admit new members.

    All groups, including public groups, can admit new members via an invitation link created by an existing member; for groups with the invitation membership setting, this is the only way new members can join. For private groups with automatic membership, the system may add new members with compatible schedules and preferences when it is matching students in the pool, and it may offer match me now links to compatible students that offer immediate membership. For private groups with membership by permission, the system may instead offer match me asap links to compatible students; these links trigger an email to the group requesting permission to add a new member; any member of the group may approve or deny this request.

    In all cases new members can join only when the current size of the group is less than any size limit that has been set. Private groups may change their membership settings at any time, but whether a group is public or private is fixed when the group is created. All groups created by the pset partners matching algorithm are private group with membership set to automatic by default.

  • Why was a new student added to my group?

    As explained above, groups with automatic membership may have compatible members added to them by the system if the size of the group is below its limit, or if no limit has been set. You can prevent this by setting the membership to permission or invitation.

  • What if I am a student who is also a TA/instructor?

    If you click on your login status in the upper right corner of the page where it says Student, it will change to Instructor, provided you have been authorized as an instructor for a class by the responsible faculty member.

  • How can the size of my group be larger than its limit?

    The limit is based on the target size of the group, which may be less than its current size. When new groups are created by the system the target size is derived from the preferences of its members. Unless these preferences are set to required students may be placed in group larger than their preference. For example, if there are 3 students to be matched who all prefer a group of size 2, the system will likely put all 3 in the same group and set the target size to 2, which will make the limit 2, rather than leaving one student unmatched.

  • Who can see the information I enter on pset partners?

    Your kerberos ID, preferred name and pronouns, departments, and year are visible to the instructors of any course you list on pset partners, and to all members of any group you join. If that group is public this information will be visible to all the students in the class. At present pset partners does not verify registration by class (nor would we want to, not everyone registers right away), so in principle this could include any current MIT student. But we strongly discourage students from using pset partners for any purpose other than finding pset groups in classes they are taking.

    The instructors of a class, which may include TA's they deputize, can view the membership of all groups in the class, including private groups, and they can see the membership setting of the group and whether it is full or not. Instructors cannot see any information about the preferences of students or groups, nor can they see your hours of availability. Department level administrators, including the department head, can see all the information the instructors in their department can see (this applies to all departments a class may be cross-listed in).

    Aggregated information about preferences and availability is intentionally leaked to other students in the class in the interest of nudging students towards choices that will make it easier for the system to form compatible groups. Every student can see their average hours of overlap with other students in their classes (a patient student could determine this figure hour by hour), and they can see the number of students that have selected each preference option, but not the strengths of those preferences. This intentional information leaking should be benign in a large class, but in a small class it may make it possible for other students (but not instructors) to deduce your preference settings.

    The administrators of pset partners can access all the information you enter. We promise never to use this information for any purpose other than debugging and optimizing the matching algorithm, and in particular, to not share it with anyone else, either within or outside of MIT. If and when someone develops a practical homomorphic encryption algorithm that we can easily use, we would be happy to offer an encryption option. Our database and web server are housed at MIT and accessible to the small number of IT staff in the mathematics department who support us and without whom this website would not be possible (thank you!). They have root privileges and can in principle access anything, but we trust them implicitly (they can already read all our email, for example).

  • How does the matching algorithm work?

    The algorithm is a work in progress, but here is an overview of our current approach, which proceeds in three phases. The input to the algorithm is a list of students in a class who have asked to be put in a pset group by joining a match pool, along with their availability and preferences. This may include preferences for group size, when to start working, collaboration style, et cetera, as well as affinities, such as a desire to be grouped with students in the same department, or a diversity of departments. The output of the algorithm is a list of new pset groups along with a list of unmatched students.

    The first phase of the algorithm is to partition the list of students into groups that satisfy as many size preferences as possible and do not violate any required size preferences; students who have not expressed a size preference are put into groups of size 3 by default, but may be placed in a groups of size 2 or 4 when necessary. There may be students who cannot be put into a group at this stage because their is no way to satisfy a required size preference (in addition to student preferences, the system will not form groups of size one).

    The second phase of the algorithm involves swapping students in different groups. Each group has a compatibility score that takes into account the overlap in hours of availability and the degree to which its members preferences are or are not satisfied, exponentially weighted by strength; this score is an integer that may be positive or negative. The net compatibility of the matching is the sum of the compatibility scores of the groups. The swapping phase proceeds by ranking all possible swaps based on the change in the net compatibility score and executing the highest ranked swap if it improves net compatibility. This step is repeated until there is no swap that improves net compatibility, which is guaranteed to eventually happen since compatibility scores are discrete and bounded.

    At the end of phase two the matching is guaranteed to be pairwise stable, in the sense that there is no pair of students who would be happy to change places, in fact there is no pair of students whose average happiness would be improved by changing places (average happiness can improve by making one student a lot happier and one student slightly less happy). But there could be a pair of swaps that would in combination make everyone happier, and it could be that simply moving a single student from one group to another would improve net compatibility. Moreover, it is possible that a different initial assignment in phase one might produce a higher net compatibility score at the end of phase two. Future versions of the algorithm will take into account a broader range of optimizations.

    After phase two there may still be students with required preferences that are not satisfied; this is rare in large pools but can easily happen in a small pool (which is why we discourage students from setting required preferences). These students are removed from their group and put in the list of unmatched students, along with any students left in groups of size one as a result. The remaining groups are then created.

    The third phase of the algorithm tries to reduce and ideally eliminate the list of unmatched students. For each student on the list the system ranks all existing groups in the class with automatic membership and space available, according to the change in compatibility score caused by adding the student to the group. This list of groups may include groups that were previously created by students or by the system in an earlier matching, as well as the groups that were created at the end of phase two. However, the system excludes groups that the student previously left. The system will add the student to the top-ranked group if the change in compatibility is above a certain threshold (the new student is allowed to reduce the group's compatibility score by a small amount, but not by too much).

    The group ranking algorithm used in phase 3 is also used to generate match me now links that are presented to unmatched students whenever they view the "Partners" panel for the class (but the threshold is higher than the one used during pool matching). This option may be disabled for students who leave groups too frequently -- changing groups when you need to is fine and even encouraged, but we don't want students to abuse the match me now option by using it too often, as it creates a certain amount of disruption in an existing group.

  • Your matching algorithm seems pretty ad hoc. Surely there are standard solutions to this problem?

    The Gale-Shapley algorithm efficiently solves the stable matching problem, which asks for a bijection between two sets with ranked preferences that is stable in the sense that no unmatched pair would both prefer to be matched with each other. This algorithm has many practical applications, including content delivery networks, admissions, and healthcare, but it doesn't really solve the problem of matching pset partners.

    A generalization of the stable matching problem that is closer to the problem we need to solve is the stable roommates problem. Unlike the stable matching problem, the stable roommates problem does not always admit a solution. There are efficient algorithms for determining when a stable matching exists and producing one when it does, but when no solution exists the problem of finding the best matching is known to be NP-hard (even finding a solution that comes within epsilon of the best matching is NP-hard).

    Having said that, the algorithm we came up with can surely be improved. If you are a student or researcher who is interested in helping us do this, please contact us. There is surely a UROP (or two) to be had...

Return to main page