Students reviewing each others code


(Yusuf Pisan) #1

I’d like to assign each student to review 2 other students’ code. All the codes are in private student repositories. I do not want a student accessing all the assignments, just the two assignment they are reviewing.

Option 1: For 40 students, create 40 teams, each team with 2 students, each team reviewing 1 repository. Once the teams are set, I’d have to visit each repository and add that team with read access. Since teams will change for each assignment, would need to repeat again for next assignment. Too much clicking.

Option 2: Setup a spreadsheet of who is reviewing whose assignment and then visit each repository and add 2 GitHub usernames with read access to that repository. Still a lot of clicking.

Option 3: Reach out to the community and see what others have done since neither #1 nor #2 is maintainable in the long term.

Once students have read access, they can create “issues”, but there might be a better way to leave feedback without modifying code. Open to suggestions.

Thanks,

Y


(Chris Cannon) #2

There is currently no built-in methods I can think of to assist with this problem. However, it seems like this is close to something that can be accomplished by the Settings Bot. Perhaps you can programmatically edit the settings.yml file in each repository to add the collaborators you like?

Also, when it comes to providing feedback, pull requests are high and above my favorite method. If your students complete all work in a branch and make a pull request at the end, there is rich line-by-line feedback that can be provided in a pull request review. You can learn more about this kind of feedback in GitHub’s teacher training program.


(Yusuf Pisan) #3

Edit: Found under: Organization > Settings > Member Privileges > Allow forking of private repositories

For assignments, forking is disabled, so not sure how to create pull requests if you cannot fork… Hmmm…

Y


(Dan Wallach) #4

I’d look at doing this with the GitHub APIs. (See, e.g., “Add user as a collaborator”.) You could hack this into an existing script (see, e.g., my script to randomly assign graders to student repos). Start with the same code (lines 1-123) to read all the repos, then you’ll be making a series of PUT calls to add the student reviewers to each repo in question.

If you want to do those assignments at random, then you’ll have all the user names from the initial scraping process, so not too much hacking involved.

According to GitHub’s documentation, “The invitee will receive a notification that they have been invited to the repository, which they must accept or decline.” That means that you’re virtually guaranteed that one or more of your students will hit “decline” when they were supposed to hit “accept”. This suggests that you want to make your “randomness” reproducible, to make sure you can re-run the process.


(Yusuf Pisan) #5

Thanks, especially on the reproducible randomness bit!