learning-unlimited / esp-website Goto Github PK

We want Etherpad for checklists!

Well, maybe. We already have some checklisting abilities, a per-class set of checkboxes; but IIRC there's no UI for creating them and they're really only useful for relatively specific things. We should have something with broader functionality.

It takes multiple minutes to load, for MIT Splash. And that's cached. Though un-cached isn't a huge amount longer.

This page should be able to load in under a minute, un-cached. For a Splash of more than half this size, I've gotten it to around 2 seconds cached in the past. So something's not working the way it's supposed to...

We store the e-mails not just of students, but of their parents/guardians, etc. The Comm Panel should be able to send to these folks.

User View pages currently show a list of classes for that user. We should display more information about those classes; times, rooms, enrollment, etc. This to reduce the need for user morphing.

Have teachers pick from a list of preconfigured grade ranges rather than pick a grade min and max

We have this snazzy system for imposing constraints on peoples' schedules. This is most commonly used to require students to attend lunch. Creating these constraints requires some understanding of the constraints system, and requires creating a bunch of records in the admin interface. We should have a UI that makes this a lot easier for new folks.

Live teacher check-in, with highlighting of teachers that need to be called because they haven't yet checked in for impending classes.

Useful if it's "live", in some sense, so multiple people can work on it at once. Possibly not necessary?

It would be nice to have a UI by which admins can update student grades, that's not the Django admin interface. (Student grades are the one thing that we don't allow students to update themselves, since grade determines which class students can attend.)

We should have counts of students in each category (Priority/1, Interested, etc) for each class in some useful display (presumably for admins?)

We have a user who reported that he entered the lottery, and received a confirmation e-mail, but upon logging in to check the results, had nothing showing. We checked, and the user indeed had no bits saved (not even any expired ones), and had no ConfEmail or Confirmed user bits set. But in the esparchive, there was indeed an e-mail sent to that user.

Registrations are saved before the confirmation e-mail is sent, so I don't know how this could've occurred.

I don't know if this is a bug in the code, or in the custom setup that MIT used.

For reference: MIT ESP user id #: 61491

It is possible (as we've seen) for the LSR interface to grand duplicate registrations. The LSR script doesn't handle this at all.

"The lottery code chooses a priority registration at random from this:

priority_ids = StudentRegistration.valid_objects().filter(user=user,
section__parent_class__parent_program=program,
relationship__name=priority_type).va
lues_list('section', flat=True).distinct()

distinct() removes duplicate rows. Unfortunately, I don't think that
multiple registrations for a student will count as duplicate rows,
since they won't have the same start time (which is in the
StudentRegistration model." - Ruthie Byers

Therefore, students with more student registrations will have an unfair advantage. We should, of course, fix the bug that grants duplicate registrations in the first place (issue #3), but we should also have a contingency plan for dealing with this in the LSR script itself.

Live teacher check-in, with highlighting of teachers that need to be called because they haven't yet checked in for impending classes.

Useful if it's "live", in some sense, so multiple people can work on it at once. Possibly not necessary?

We should flush out our UI for teacher training and interviews; have a way for admins to set them up that isn't the Django admin interface.

We store past versions of QSD pages. We should have a UI that lets people flip through past pages.

Students can register for walk-in seminars in FCFS

Google's Closure JS compiler is great at catching the small handful of little annoying syntax bugs that cause ~90% of our IE JavaScript compatibilities. We should write a test that throws all of our custom JS at Closure and sees what sticks. Much faster to see all the issues in one go, than to play whack-a-mole running through the IE tests and tracking down problems one at a time.

This is technically a bug in scheduling, but ... if a class spans both lunch blocks, LSR will place students into it.

We have a Comm Panel. We also have a mechanism (a Program Module, I think?) to gather students' numbers to receive text messages. It'd be nice if you could use an interface like the Comm Panel to send text messages to people.

Or, possibly, some other interface; I think the initial set of sets of people who'd want to be able to receive text messages is comparable to the set of Mailman lists?

When we display multi-hour classes in some places (student and room schedules), we show one block per hour. We should merge them to one row per class.

If I click on the "view" button at http://esp.mit.edu/teach/Splash/2011/teacherreg , it takes me to http://esp.mit.edu/teach/Splash/2011/editclass/5553 , which tells me "Sorry, teacher registration is closed. This may be because you are either too early or too late."

I'd imagine that link should take me to a page for viewing (but not editing) my class.

• Number of class hours
• Whether student requested text messages
• Individual teaching and interviewing slots

(If you know how to add filters in general and you know how to query for something by hand, it's very easy to add a specific filter. But you have to learn those two things first, which takes some effort. So the "Easy" tag is conditional.)

A message box at the top of http://esp.mit.edu/teach/Splash/2011/class_students/5553 tells me: "Note: You can email your students using C5553-students@localhost"

This has been requested. I'm not exactly sure what it is; could someone comment further? (I assume a UI to do attendance tracking?)

I've observed that, on MIT ESP's site, the catalog page is not consistently served from HTTP cache.

Not entirely sure why, but there were a lot of cache misses, each of which was pretty expensive.

I noticed the same issue on the catalog_json view as well.

In many cases, LSR is creating two identical student registration bits for each class that a student expresses interest in.

Well, not exactly identical. The start_time's for the two student registrations differ by some number of seconds. So it's possible that these users are submitting the lottery twice. I'm not convinced this is the case though, given the large percentage of users who seem to be experiencing this problem. See, for example, http://esp.mit.edu/admin/program/studentregistration/?section=6952&ot=asc&o=3. The number of student registrations is about double the number of students who actually registered for that class.

It would be cool if http://esp.mit.edu/teach/Splash/2011/substitute.html automatically figured out what my name and e-mail address were.

The checking only happens on AJAX requests. I'm in the process of a fix that entails looping through all the forms, and adding an onsubmit which calls check_csrf_cookie(this).

We currently log past queries and past e-mails sent through the Comm Panel. We should expose this information; make it possible to re-run queries, view previously-sent e-mails, etc.

This possibly wants to be multiple tickets. If you want to implement just part of this and have a UI idea for it, feel free to split the ticket.

When you go to submit your registration in LSR, the UI sends a POST request immediately with the form's contents, but doesn't display anything in the UI until the server responds.

Unfortunately, the 'submit' view can be very slow; tens of seconds at least with a large schedule. Arguably we should just do something to speed up the view; I really don't see any good fundamental reason why what that view is doing needs to be so slow, though the way it's doing it, analyzing one class at a time and inserting one Reg bit at a time into a heavily-indexed table, I don't see an alternative that doesn't require a structural change.

Regardless, there's no UI feedback, so users don't know what's going on; they wander away figuring something's broken, or click multiple times and possibly get errors back, etc.

With lottery reg, the current main StudentReg page displays all of your lottery and enrolled class options all at once, and is designed to be able to let you edit them, etc. It'd be great to have a simple page that just displays enrolled classes.

The "Allow registration from catalog" setting (in the student class registration module info model) currently doesn't do anything. The code that cared what this was set to was removed. I don't know if this was intentional or not. If this was intentional, we should remove the setting, because it is misleading. If it was not intentional, we should add the functionality back.

would be a great thing to have, so that it's not so much of a pain if users get disconnected / encounter an error / etc.

It can also let users know right away if something's going wrong with their lottery prefs; and it will tend to reduce duplication in the reg records.

Template changes made in the repository need to be propagated to template overrides. This may be difficult to do automatically, but we could implement a script that checks whenever the code is pulled and notifies the user of any overrides that need to be updated, much as the DB schema notify script checks for pending migrations.

for QSD pages

In the embedded schedule on /studentreg, it is non-obvious to many students that they are enrolled in multi-hour classes. Instead, they think they are enrolled in the same class multiple times. We should find a way to improve the text to make this more obvious.

Have to think about what to do about people who don't identify as simply M or F. Also people who don't want to specify?

The schedule-constraint system should be able to disallow gaps (periods of times without classes) in schedules

Many students don't see the grade selection drop-down box when filling out the profile for the first time, and therefore are assigned the default grade level (i.e., the lowest available grade). We should change this widget to one where there is no default option, that way if they miss the box, they won't be able to submit the form, and will be prompted to select their grade.

We should add a field to QSD pages where people can take notes on what's going on, that won't be shown to users viewing the page

We should have an "opt-out" link at the bottom of all e-mails sent out through the site.

Adding this to all Comm Panel e-mails would be a great start.

"The catalog shows all class titles/teachers (the title block), but nothing shows up underneath. It doesn't say anything like "you are not in the correct grade for this program". This is a REALLY minor bug." - Gurtej

We have an HTTP caching proxy running in front of most production instances of this site. Looking at MIT's site, it looks like it's setting the "Vary: Cookie" header even on pages that are not per-user pages. Which means that everything is cached per-user; which is largely unuseful as peoples' Web browsers already do that for us.

At minimum, the Catalog and QSD pages should no longer set this header.

It seems that ExtJS creates large numbers of DOM objects (mostly

We have a page that people can submit tickets through. We should have an interface through which people can view and respond to these tickets.

We have a page that people can submit tickets through. We should have an interface through which people can view and respond to these tickets.

We should have an "opt-out" link at the bottom of all e-mails sent out through the site.

Adding this to all Comm Panel e-mails would be a great start.

At MIT Splash, a bunch of people were added as coteachers by an admin morphing into an existing teacher and adding them via the Coteachers registration widget. These people didn't get added to the program Mailman mailing list. They did receive the correct UserBits, however.

I think we should come up with a more-elegant general solution to adding people to lists and removing them from lists. Possibly adding an event listener on userbit-save and interpreting the results and updating lists accordingly on each save. But the immediate fix, editing the Coteachers view to update mailing lists, should be easy enough.

We should log account-activation e-mails, and allow (and have a UI for) re-sending them

There are instances where, after LSR completed, a Priority/1 student was not placed into a class that had open spots.

We should have more-precise membership controls for users, so the only option isn't just to disable the account