PT Course Staff access to Center Accommodations

On our campus, instructors have primary responsibility for Accommodations. No PT Course Staff Roles seem to permit even the viewing of Center Student Accommodations; as the responsible party, we have an instructor making a good case to need to be able to confirm Center Student Accommodations.

Our only workaround is to add Course Staff to Center Staff; the downside is that even at the lowest level (Proctor), suddenly Course Staff could affect CBTF operations, which is not their domain.

Can there be a "Read-only" role for Center Staff? Could Course Staff Owners by default be given permission to view /pt/center/NNNN/staff/course/MMMM/students, which would reveal Center Student Accommodations?

We could imagine other solution pathways, including scenarios in which PT Course Staff could edit Center Student Accommodations (while not being able to start/stop Exams or delete Center reservations), but thought we'd start here.

Thanks!

IMO we should jump straight to considering the "other solution pathway" you shared above: allow centers (on an opt-in, default-false basis) to elect to make all accommodations viewable and/or editable by Course Owners. We can then include appropriate warnings that the center admins should consider the institution's policies before enabling it. For instance, this would absolutely not be appropriate for UIUC, where it's my understanding that students must retain control over who they disclose disability/accommodations information to, and where the significantly larger scale means that we don't want hundreds of random TAs to have control over student accommodations.

To be a little more precise: if this hypothetical setting is enabled, a Course Owner within a given course could see, for any student who has accepted an invite to their course, the accommodations for any center that the course is linked to. "For any student who has accepted an invite to their course" is an important part, as this would prevent an owner of one course from enumerating the accommodations of every user at the institution, or adding accommodations to random users. This would mean that the process of adding accommodation would still be pretty serial:

Course staff must invite the student to the course
The student must accept the invite
Course staff can then add accommodations

We wouldn't allow course staff to create new center-level accommodation types; we're assuming that it's up to the center to enumerate which accommodations they're prepared to support. But course staff would be able to view all accommodation types in the center and pick the appropriate ones for their students.

@gmerritt Would this meet your needs? I understand that Berkeley is operating in an exceptionally high-trust environment with (from what I can see) fewer concerns about student data privacy than many other institutions we work with, so I'm trying to build something that will work at your institution while still being useful for folks who don't operate as close to your end of the trust/privacy spectrum.

@mwest1066 this design would have implications for the question of whether we should allow instructors to force-enroll students (see point 3 of https://github.com/PrairieLearnInc/PrairieTest/issues/1572), as this would allow leakage of private sudent information. Given that, I'm not actually sure if this proposal for course staff to view/edit accommodations is the right way to go.

@nwalters512 it's not particularly that berkeley is an "exceptionally high trust environment" but rather that historically, ultimate responsibility for accommodations here devolves directly onto the course instructor, so that has always been the communication pathway for accommodations. in practice, the mechanism by which instructors access this info is a fairly heavyweight one - the info is deliberately hard to disseminate - so it isn't really high trust. that's what makes our situation tricky - we must rely on the instructor as the source of the info from DSP, but the instructor in turn must currently have an intermediary (Center staff) to whom they convey it.

given UIUC's workflow, i can understand why you believe that "having course staff view/edit accommodations is [not] the right way to go." but at UCB, it is the only way, i.e., PT aside, course staff are the only other people (besides DSP staff) who are given access to this info. this will be the case until (and if) we can get our DSP center to adopt a similar "direct-to-CBTF" workflow for accommodations, which we agree would in many ways be ideal, but it will take time to get there. i don't know how other UC campuses' workflows around this are structured, but right now i'd say PT makes assumptions about workflows and disability-information-sharing that simply may not match the reality on the ground in some places.

i would love if michael ball (@cycomachead) could weigh in as he is one of the faculty members most familiar with/advocating for/knows the realities of managing student accommodations. thanks for engaging with us on this.

There's lots here, but as a faculty member, I need the ability to see and manage details about student accommodations, and I need a TA to be able to do that too. This doesn't need to be on by default, though my institution-wide defaults make sense). When I mention high trust, it's also about the TAs, where I expect folks on my course staff to be able to make reasonable discussions about student's needs. I also usually expect this to happen after individual discussions/emails. What armando said is all true, though I will add the practical complexity that this includes our TAs, or at least a subset of them. (Without TAs involved, this place would fall over....)

Part of the problem is that, w.r.t. to accommodations, they are constantly changing...and it's not reasonable for me to expect a staff member to respond to requests in minutes or hours.

Course staff must invite the student to the course The student must accept the invite Course staff can then add accommodations

This workflow is mostly reasonable, but I see no reason why (in theory) an invite request cannot also lead to a 'center' / enrollment / some other editable record being created. This would reduce the dependency on waiting for a student to complete come step. It would, in the future, also allow us to do things like automate getting data into PT.

For me, the problem is (students add / dropping, accommodations being added / removed, quiz sign ups open, past quiz might be closed) are all simultaneous steps, especially during the first few weeks of the course. And ultimately, if it is my responsibility as an instructor to ensure student needs are met, then I need to have visibility into that process.

There are other options here that could help, where PT could make it easier to manage instructor<>student communication w.r.t. accommodations. For example:

If a student's needs are updated such that a seat conflict now exists for an existing reservation, a warming message + option to send an email to the student would be welcome.
if a student goes to make a reservation and there are no seats available that match their accommodations:
- you could give the student the option to say 'i don't need the X accommodations'
- student can optionally send a message notify course staff so I'm aware something is potentially wrong

Part of the problem is that if scheduling flexibility is given to (nearly) all students, we need to find a way to try to provide that flexibility for students for whom the CBTF doesn't have a seat, and I've already head from a couple students that flexibility >>> some specific accommodations, that they're willing to "give up". [This can definitely turn into a gray area, but we're already there... In that sense, student agency is a valuable desire.]

Some of this is specifically about permissions, and some of this is more about user flows. But when a student runs into an issue, they cone to the instructor or TAs and right now it's exceptionally hard to help them. We need to involve a 3rd party (who probably has more of a life), which increases the time and complexity.

In general, when it comes to enrollments, I don't believe in invite codes. There are bad UX; they lead to data inconsistencies, and they cause delays... This gets to the other issue about enrollments more broadly, but in my mind, both as an instructor and engineer, there is exactly one roster. All students in the course are on that roster, and every tool I use should have exactly the same set of students (and course staff....)

Before responding to the above (thanks for your detailed replies), I wanted to share a new proposal that Matt and I just came up with. I think it will let you do what you want while still respecting student privacy.

An institution will be able to choose to defer all accommodation management to courses on a center-by-center basis. In this mode, it will be the sole responsibility of course staff (Owners/Editors) to manage accommodations for all of their enrolled students who are taking exams in the center. It's still up to center staff to defined what accommodations are supported. Center staff will be able to view but not edit the accommodations for a particular student.

These accommodations will exist at the intersection of a center, a course, and a student enrolled in that course. So it will be up to each course to add/remove/manage accommodations for its own students; accommodations added for a student in one course will not bleed over into any other courses that student is enrolled in.

Let us know what you think about that! Now, to respond to some of your points/suggestions:

given UIUC's workflow, i can understand why you believe that "having course staff view/edit accommodations is [not] the right way to go." ... right now i'd say PT makes assumptions about workflows and disability-information-sharing that simply may not match the reality on the ground in some places.

This is a subtle point, but I said " I'm not actually sure if this proposal for course staff to view/edit accommodations is the right way to go" (emphasis mine). I don't want to give the impression that we think there's a single right way to do things and/or that UIUC's way is that way. It's true that the initial PT design and feature set was heavily influenced by what UIUC has learned from nearly a decade of running a CBTF, but we've been making PT more flexible since the moment other institutions started using it. This is just part of the product development process; thank you all for engaging with us on this, too!

There's lots here, but as a faculty member, I need the ability to see and manage details about student accommodations, and I need a TA to be able to do that too. This doesn't need to be on by default, though my institution-wide defaults make sense). When I mention high trust, it's also about the TAs, where I expect folks on my course staff to be able to make reasonable discussions about student's needs. I also usually expect this to happen after individual discussions/emails.

What armando said is all true, though I will add the practical complexity that this includes our TAs, or at least a subset of them. (Without TAs involved, this place would fall over....)

This is helpful context; the takeaway for us is that this functionality should be available to course Editors, not just course Owners.

This workflow is mostly reasonable, but I see no reason why (in theory) an invite request cannot also lead to a 'center' / enrollment / some other editable record being created. This would reduce the dependency on waiting for a student to complete come step. It would, in the future, also allow us to do things like automate getting data into PT.

We will support adding course-controlled accommodations before a student logs in or accepts an invite. This wasn't done for center-controlled accommodations because our data model has no notion of a student in a center in isolation; a student always belongs to a center through a course enrollment. For course-controlled accommodations, this capability will naturally fall out of the fact that we'll associate these accommodations with an enrollment, which exists before a user accepts an invite (and indeed before a user logs in). For instance, you can already create reservations for an enrollment that hasn't been accepted; the same will be true for this new kind of accommodation.

if a student goes to make a reservation and there are no seats available that match their accommodations [...] you could give the student the option to say 'i don't need the X accommodations' ... This can definitely turn into a gray area, but we're already there... In that sense, student agency is a valuable desire.

We're fully in agreement regarding student agency, and this is already on our internal roadmap (https://github.com/PrairieLearnInc/PrairieTest/issues/1053 - only visible by PL staff).

In general, when it comes to enrollments, I don't believe in invite codes. There are bad UX; they lead to data inconsistencies, and they cause delays... This gets to the other issue about enrollments more broadly, but in my mind, both as an instructor and engineer, there is exactly one roster. All students in the course are on that roster, and every tool I use should have exactly the same set of students (and course staff....)

We're in full agreement here as well. We're driving towards unified rosters via LTI. It will take some time before we get this fully implemented and deployed, however. This also relies on your campus IT folks getting us wired up for LTI, which is currently in its early stages.

I'd value your input and experience with regards to rostering, but this is getting off topic for this issue. Let's find another venue to have that conversation.

@nwalters512 and @mwest1066, in the proposed new scenario, how would this relate back to seat groups? Like the Center Location Seat Group Accommodations.... https://us.prairietest.com/pt/center/1329/staff/settings/accommodations

Would the Center Owner need to first define all known accommodations that will be in play, and then the Course Owner finds the Center's Accommodations when modifying the Student record?

It's still up to center staff to determine what accommodations a center will be able to accommodate, to associate those accommodations with specific seat groups, to manage and monitor capacity, all that good stuff. Ultimately, accommodations will always be a dialogue between the student, the course instructors, and the center staff.

Thanks, this makes sense.

I think this should work well. The main caveat is that I think it needs to be clear to the person adding/selecting accommodations what happens if they are "0 seats available' or something like that matching a condition. This is kind of tricky, since the 'check' that I want to happen at this time is more 'theoretical' -- e.g. a warning shows up if it is a guaranteed a testing center (all testing centers?) will not be able to support a student.

Ideally, then, when scheduling an exam, I should be able to see the set of students who can't be served by the selected testing center(s). I'm not sure what view is right for this -- it's sort of an aggregation of all set of current reservations, as well as the 'sessions' view. But that would help really get to the problem, which is students that need specific coordination. Solving this problem once for the course would be great, but since it can potentially change on a per-exam exam basis, it would be helpful to have that view.

I guess the high level goal would be, with respect to exams, PT because the 'source of truth' for a course. Without PT, I do need to maintain some spreadsheet myself. But now, I need to maintain a smaller sheet and keep PT up to date, which feels like more work, and more fragile.

PrairieLearn / PrairieTest-feedback

PT Course Staff access to Center Accommodations #70