[jpolitz]

I use Github in my courses, and I was excited when I saw this. Three responses:

1. The permissions screen immediately irked some of my collaborators – why does this need access to _everything_, including deleting repositories that already exist? They pointed out that if one privacy/security-conscious student makes a stir about this in an undergrad course, it's all of a sudden a potentially huge issue. And I teach my students to be suspicious of screens that ask for too many permissions, with good reason!

2. Can I connect this to my institution's internal Github enterprise? I currently manage assignment distribution and collection with hand-rolled Github scripts that run against our institution's deployment. Do the teachers_pet scripts work in that environment as well, or is there Classroom-specific setup required to make that work?

3. On the screen where I choose organizations, there was a text box for a new organization, and a dropdown. I thought I was making the choice to create a new organization, but it seems to be creating all the repos in an existing organization selected in the dropdown. This has caused a lot of folks to all of a sudden get signed up for automatic notifications who are members of the selected org. That's annoying, now I have to clean up after Classroom and figure out what went wrong. I doubt that adding random student repos to an existing organization is ever what a new user wants, and I tried to follow the flow that (I thought) would not accidentally do that. It seems like a Classroom organization is a different thing from a Github organization?

[johndbritton]

1. We're working with the OAuth permission model that exists today, but I've passed along your feedback to our platform team. The generic use case for Classroom for GitHub is to create a new organization to use for student assignments and use Classroom for GitHub to manage that organization. If / when you decide to stop using Classroom for GitHub you can remove your organization and it will clean up after itself.

2. GitHub Enterprise is not supported, but others have requested this feature: https://github.com/education/classroom/issues/240

3. I'm having a hard time understanding your situation, but would appreciate it if you could file an issue at https://github.com/education/classroom/issues/new, can't promise that it will be fixed immediately, but need to gather feedback like this.

[jpolitz]

Thanks for the response! Related to (1), the issue was more that when a _student_ visits an assignment page, they get the same big permission list as an instructor; it makes sense that instructors might need a plethora of permissions. Is that necessary for students?

Issue for (3) reported here: https://github.com/education/classroom/issues/250

[johndbritton]

Thanks for the report. Your point about (1) is well taken, maybe file an issue on that too and we can discuss ways to improve.

[wbillingsley]

A couple of things I've found, using GitHub for individual assignments (I also use it in another unit for a class-wide project, where it works very well)

- user management is a bit of a pain. Students are always late getting their github usernames to me, often with typos, and there are three different dates during term when the class-list changes (last day to enrol, last day to withdraw without incurring a HECS fee, last day to withdraw without academic penalty). If you could do an LTI endpoint, that would be helpful, as most LMSs support LTI. At the moment, we're considering running GitLab instead, as that supposedly has LDAP and so can use our university server logins.

- using teachers-pet (GitHub's command-line tools) for assignments this term, I found an issue where a student made a public fork of their assignment repository. Unfortunately this is problematic, as it could cause students to (accidentally) run into trouble with university plagiarism policies (where putting your work up for others to plagiarise in an assignment is also outlawed).

[johndbritton]

Those are two very common issues that we've tried to address with Classroom for GitHub.

You no longer need to collect usernames, just distribute an invitation URL and have your students include their student number or name in the repository description or README.md.

Forking is intended as a collaboration tool, so it makes sense that every member of the network can see all forks in the network. In a classroom setting, however, this might not make sense. Classroom for GitHub doesn't utilize forking, instead it creates independent repositories and pushes the starter code without using forks.

[orangea]

As for #1, students and instructors can simply create a new github account specifically for any given course and not connect it to any of their personal information or other github accounts/repositories if they are security-conscious.

[johndbritton]

This is a highly discouraged solution, multiple accounts lead to trouble with students and their local git configurations. They have to be knowledgeable enough to keep things separate.