Implement "Student Identifiers" to map between GitHub users and Students

[samwhitlock]

A feature request: an optional, text-field identifier associated with each student.

The use case: instructors want to the relation between GitHub users and students in their class. For grading purposes, instructors need an unambiguous way to associate these 2 identities for each enrolled student. Students often have similar / alternate spellings for their names, or don't even use their real name at all in their GitHub profile.

Instructors currently do this by having students fill out a separate form (e.g., Google forms / spreadsheet).

To accommodate all possible use cases, this field could just be an additional text field (e.g., to ask for their school ID).

An option that would be quite useful along these lines is if this student ID could be the academic email addresses of students. In this mode, students would enter their academic email address and would be verified by an email to that address. It may also be desirable to limit the domain of the email address (e.g. only epfl.ch, stanford.edu, ...).

[johndbritton]

To accommodate all possible use cases, this field could just be an additional text field (e.g., to ask for their school ID).

This sounds reasonable to me. We'll consider giving the teacher the ability to make the field required.

In this mode, students would enter their academic email address and would be verified by an email to that address.

I think it's unlikely that we will go so far as to send an email validation.

It may also be desirable to limit the domain of the email address (e.g. only epfl.ch, stanford.edu, ...).

I think this is a separate feature, see #377.

[johndbritton]

Would love to hear from other teachers about how helpful it would be to have a text-field identifier for the students and if there are other implementations that achieve the same in a superior way.

[samwhitlock]

To elaborate more on what I'm using for my course(s):

• I use this home-brewed github management application
• It primarily relies on students filling out a google form, to fill out a copy of the template spreadsheet.
• The main function of the spreadsheet is to link github IDs to the GASPAR usernames (the username for the Kerberos clone at my institution), which is how the app names individual assignments. There is some LDAP functionality in this script, but it's not necessary (just to fill populate info if we only have an email or a student ID number).

This is somewhat hacky, but it's what we've been using.

[connorcartwright]

Hey @samwhitlock @johndbritton

I'm interested in giving this a crack but had a couple questions before starting.

Assuming we wanted the identifier to be set at a classroom level there could be an optional field on the classroom creation screen (if the classroom is already created, set in the 'Manage classroom' options) which lets the teacher set what the identifier is based on.

Here we need to think about options, whether it's:

• A specific email address (i..e. academic, e.g. ___@cs.bham.ac.uk)
• A personal email address (any email)
• GitHub login
• Other social logins

Or something less controlled, like a nickname or any text the student wants to type in.

I think for teachers it may be more useful to limit what the student can type in, for example, limiting to an academic email lets the teacher check if the student is enrolled.

I'm assuming the teachers will want to know for sure who a student is and that they are actually enrolled in the course, which would need some form of authentication (e.g. the student getting sent an email).

[johndbritton]

I've been thinking about it like this:

• Give the teacher the ability to specify a string that describes what the student should enter: (student id number, email address, etc)
• Give the teacher the ability to provide a list of said identifiers
• Only let students with the provided identifiers into the Classroom
• Let teachers manage groupings based on the pre-loaded identifiers and users that have joined

@tarebyte might have some other ideas for this as well.

[cyhsutw]

And maybe we can also create the assignment repo based on the identifiers, which would be much easier for teachers to grade.

[cyhsutw]

This a tiny prototype based on @johndbritton's comment.

Basically, the teacher can upload a list of the identifiers (.csv) and the students can link their GitHub account with the identifier (per classroom base).

This is how it looks like:

For teachers:

For students (they only need to do this step for one time):

Not sure if this worked for all of the teachers, but in our institute, teachers can download a csv file containing names, student IDs, email addresses of the students who enroll the course.

[johndbritton]

I think this is on the right track. A few notes:

• The term "Student ID" should be configurable as some schools might use an ID number while others might use an email address or something else
• Uploading a CSV is nice, but what if it has multiple columns, how does the user choose which one represents the identifier?
• We'll also likely need a way to unlink an identifier from a user account, as it's possible for a student to guess another student's ID number
• This is a major change for the app, I think we should put it behind a feature flag and enable it for beta users only up until the point where we know things are working well and we've found a solid solution that works for the general case
• The solution here could be made more generic to support the idea of student passwords. The idea being that we distribute an invitation link along with a password for each student that allows only that student to link his or her account with a given student identifier in the system. See https://github.com/education/classroom/issues/377 for some more info on this problem.

[connorcartwright]

I would think using 'Student Identifier' as the term would be a bit more generic.

I imagine most teachers would find taking the students' academic email addresses and then having classroom send the students a confirmation email upon accepting the invitation would be the best solution.

If we use ID numbers or a similar text field, then as you mentioned @johndbritton it could potentially be guessed/abused.

Without the teacher having confirmation (which can be guaranteed by confirming academic email addresses) that their students are the ones accepting the invitations, the identifier loses value.

I like the idea of using a passcode/password for each student (as mentioned in #377. However, in order to distribute the password the teacher will probably have a list of emails, in which case, sending a confirmation email to each student could be simpler?

[johndbritton]

I would think using 'Student Identifier' as the term would be a bit more generic.

We have to display something to the student on the invitation page. If we say "enter your student identifier" to everyone, that's just an ok experience. It'd be better to say "enter your school email address" or "enter your student id number" or "enter your secret code".

I imagine most teachers would find taking the students' academic email addresses and then having classroom send the students a confirmation email upon accepting the invitation would be the best solution.

That would be nice, but I'd really like to avoid having this app send emails if possible. GitHub already has a system for adding emails to an account and verifying them and I don't want to rebuild that here.

it could potentially be guessed/abused.

Yeah, that's true. Using email invitations can also be abused, see: https://github.com/education/classroom/issues/107

[connorcartwright]

We have to display something to the student on the invitation page.

Oh I see - I was thinking more on the organisation side only.

We could let the teacher define the term (academic email, student id number, etc.) in the classroom settings, and then on the invitation page, the students can then see that term.

For example, the invitation could say "You will need an academic email address from the University of x" to accept this assignment.

That would be nice, but I'd really like to avoid having this app send emails if possible.

Assuming the teacher has a list of student email addresses (academic or not), they should be able to set their list of students at an organisation level, as well as for a specific assignment.

On the assignment invitation we could then run through the email addresses the student has linked to their GitHub account - if a matching email address is there and verified, they can accept the invitation - otherwise we could provide a link for them to add the relevant email address and then instruct them to verify it and try again.

The teacher could set an Assignment Information setting which could read something like This invitation is for students enrolled in x course at the University of x. This could be set at an organisation level (a generic message) as well as for a specific assignment.

On opening the invitation link the students would be able to see this information and would know they were in the right place - this would make it easy for them to confidently accept the assignment.

[johndbritton]

On the assignment invitation we could then run through the email addresses the student has linked to their GitHub account - if a matching email address is there and verified, they can accept the invitation - otherwise we could provide a link for them to add the relevant email address and then instruct them to verify it and try again.

We could do this, and I have experience with a similar flow on education.github.com, but it's not very convenient for the user.

[connorcartwright]

We could do this, and I have experience with a similar flow on education.github.com, but it's not very convenient for the user.

In that the user has to go to another tab to add the email address?

It looks like it would be possible to use the API to add the email directly from the assignment invitation page, the student would then just need to verify it from their email account.

[johndbritton]

It looks like it would be possible to use the API to add the email directly from the assignment invitation page, the student would then just need to verify it from their email account.

That's great, I hadn't thought of doing that. If we take this route, then we could potentially enable restriction by domain at the classroom level.

[connorcartwright]

That's great, I hadn't thought of doing that. If we take this route, then we could potentially enable restriction by domain at the classroom level.

I think this would be the best way - it would allow teachers to easily link their student emails to GitHub accounts.

[connorcartwright]

I was working on the UI for this earlier and think that in the organisation settings we should have a 'Student Authentication' field, and allow the teacher to select one of a few options including:

• Email Domain (student has to have a matching email address, i.e. ending @bham.ac.uk, to accept the invitation)
• Email List (teacher uploads or inputs a list of emails, student has to have a matching email address in the list to accept the invitation)
• Password/Passcode (could be used in conjunction with an email domain/list, or just a general password for all students)
• None (the invitation can be accepted by anyone with the link)

We could then also override the default (organisation) 'Student Authentication' setting in individual assignment settings.

[johndbritton]

in the organisation settings we should have a 'Student Authentication' field

The four cases you described:

• None - this is what we have now
• Password - I think we can skip this one for now
• Email domain - This should prompt the user to say they need to add an @example.com email to their account and verify it. When they add it, it should update to show that it's awaiting verification, and once verified the assignment can be accepted.
• Email list - I don't like this as much because there's no way for the student to know which email address they need to add, maybe skip for now as well.

[connorcartwright]

I was working on this earlier and have added in the option to add an email domain on organization creation as well as within the organization settings, so it looks like:

I'm going to work on the invitation side next and hopefully make a pull request soon.

I think using an Email list in conjunction with an email domain could be useful, this way the student knows that they have to register their school email address, and if they are still denied access, we could provide an error message telling the student that they're not registered for the assignment.

[connorcartwright]

I've made some good progress on this and have implemented it so that teachers can add multiple email domains (comma separated) encase they have students from different schools attending joint courses.

At the moment when you create a new assignment the default email_domain value is the organization level email domain but this can be edited to allow the teacher to specify the email domain(s) at an assignment level.

I just need to clean up the assignment invitation page to allow the user to add in an email if they didn't already have an email address matching the domain(s).

[drbeco]

Just to make a point: some universities doesn't have (give) emails for the students (just for teachers and staff) nor they use student IDs! The student is identified by his/her official ID (government ID, security number or passport).

[dinever]

@drbeco Thanks for the feedback. We're working on a more generic method that fits all of the situations.

[johndbritton]

Just to make a point: some universities doesn't have (give) emails for the students (just for teachers and staff) nor they use student IDs! The student is identified by his/her official ID (government ID, security number or passport).

In the case that they don't have an email identifier or student number, there's no need to use this feature. They can be identified by their GitHub logins as things work currently.

[DarcyCK]

@samwhitlock - cc @nsqe - was looped in on the pull request associated with this feature. how was student data privacy and any possible requirements to comply with FERPA assessed in relationship to this new feature?

what is the final set of data types being collected against the student and stored in GitHub? (meaning was there a discussion and it was deemed non-relevant?)

[dhowe]

any update on this?

[stephenlevitt]

Is this still a work in progress or has it been canned? Such functionality would be a really useful addition to GitHub classroom!

[nwoodthorpe]

it seems this was half implemented, then forgotten about. There's lots of other stuff going on right now, but hopefully we'll be able to finish this up sometime soon.

[stephenlevitt]

Great

[nwoodthorpe]

We're beginning work on this again!

I'll post some designs in a bit.

We've decided to build out the idea of "rosters", which is just a list of mappings between GitHub users and some sort of identifier. One key question is whether or not a roster should belong to a Classroom or a User.

@johndbritton After our chat, I had an idea about whether or not rosters should belong to Classrooms or Users. What if a roster has_many classrooms, and a classroom belongs_to a roster. Then, when a user is creating a new classroom, they can choose from any existing roster that is associated to them through their classrooms? This way, rosters exist independently of Users and Classrooms, and we don't need to worry about the case of a User or a Classroom being deleted or abandoned.

We're also thinking about doing some more work around better grouping management. There's some cool work that was done in #707 around this. This may be something we ship after V1, we already have a lot going on with this feature.

[nwoodthorpe]

Flow:

During the process of creating a classroom, the teacher will be prompted to create a roster. Creating a roster is done by providing a newline-seperated list of identifiers, + a name for the identifier type. Providing the list can be done by pasting into a box, or uploading a csv/txt file.

Once a roster is uploaded, there will be an option to manage the roster from the classroom settings. The roster management UI is a 2-tabbed list. One tab is "Students" representing all students in a classroom. This includes students that have, or have not linked their GitHub account by accepting an assignment. The other tab is for GitHub accounts that haven't been linked to a student. In this menu, teachers will be able to unlink and link students and GitHub users.

This management page will also have the functionality to create or delete students, incase students drop the course or students join late.

The view for Assignment/Show will change for classrooms with rosters. The list will have a row for each student, not assignment repo. For students who've accepted the assignment, it'll look the same as it does now. For students who haven't, we'll show a row saying they haven't accepted, possibly with a repo_detail from #920

The view for GroupAssignment/Show will also change for classrooms with rosters. We'll still show all teams, but we also want to show the teacher which students have not yet joined a team. We can either have one tab for teams and one tab for students not yet on a team, or we can have a bar overtop of the teams showing users who haven't joined, possibly a horizontally scrolling list of avatars. From here, we could add students to teams manually.

I chatted with @johndbritton and @mozzadrella about this stuff in a meeting today, tagging @tarebyte for context.

[obcode]

@nwoodthorpe would it be possible to reuse a classroom in the next term with a new group of students or do I have to create a new one each time?

[nwoodthorpe]

@obcode We're currently working on abstracting away assignment lists and other things from the classroom. This way, you can create a new classroom at the end of the semester and choose to re-use the list of assignments from a previous classroom. Would this solve your problem?

[nwoodthorpe]

Technical implementation:

Students represent a single student on a roster. A Student belongs_to a roster and optionally belongs_to a user. If the user_id is present, the Student is linked to a GitHub account. A student has one field, their identifier string.

Rosters represent a collection of students. A roster has_many Organizations. A roster also has_many Students. A roster has one field, the name of the roster identifier (e.g. "Email").

Does this make sense @johndbritton @tarebyte?

[johndbritton]

My only suggestion here is to use a different name for the Student class. Student implies that the object represents a human person, but the relationship you're suggesting is each Student can only be on one Roster. To avoid confusion consider renaming to RosterEntry or something else so that the concept is more clear.

[nwoodthorpe]

:+1:, good point. I like RosterEntry

[nwoodthorpe]

This is now fully staffshipped. It will be full shipped soon, after some user testing.

Closing!

[avatar-lavventura]

Well each student can accept invitation by signing themselves with other student's info. When accept page show up there are available student list for them to select. How could we check that student actually select the information that links to his information.

Your teacher has configured this classroom to pair GitHub accounts with identifiers. Please select yourself from the list below. You can also skip this step for now. id_1 id_2

So student having actual id_1 can select id_2. @nwoodthorpe