I’m teaching a course for the second time this fall using materials developed in GitHub last spring and stored in a GitHub organization. Since the course materials already exist and are in public GitHub repositories, I’m wondering what people do to manage them and avoid confusing the students with too many visible repositories for future lessons, exercises, etc.
My question is what do you do with the course materials when re-teaching a class? Do you…
- Hide the future lessons/exercises by making the repositories private?
- Keep all past course materials publicly available to the class even though they may change prior to their use in class?
- Use branches for different years/semesters?
- Do something smarter that I’ve not yet thought of?
What about old student repositories generated using GitHub classroom? Do you…
- Keep all student repositories, since they will possibly be used in the future by the students?
- Ask students to fork their repositories and delete the old private copies in your organisation?
- Just delete the repositories with reckless abandon?
- Use a better solution?
Any feedback would be welcome. I’m sure this will touch on some philosophical GitHub issues, and I should say I don’t have any bias. I just want a solution that allows me to keep the existing materials easily accessible for my use/modification and minimises student confusion.
We see a lot of teachers create an organization per class per semester (example
class101-fall-2016), allowing them to retain students’ work. They simply apply for free unlimited private repositories for the new organization before classes begin (remember that it may take up to two weeks for us to review applications in peak periods such as the start of a new semester.)
Teachers may also apply for free unlimited private repositories for their individual account. I’ve seen assignments stored there, then forked into the organization for that semester as needed.
Hope that helps!
I only used one “syllabus” repository last semester.
I created a “tag” at the end of Spring, and pushed it.
Then I deleted everything except the README.md, and created another tag for the start of the Fall semester.
Whenever I need anything from the previous semester, I just navigate to the old tag,
For the course material, I just “archive” the repo by changing the name (to include a year suffix) and change it to private. I then cherry pick commits (and optionally modify) from there to the new (current) repo as the semester goes…
For student repos I have one big archive repository where I push all the student repos/branches to after a semester ends. For example, for year 2015 the branch BRANCHNAME from a student’s repo STUDENTNAME will end up as a branch 2015-STUDENTNAME-BRANCHNAME in that archive.
Keep all past course materials publicly available to the class even though they may change prior to their use in class?
Yeah, I keep everything on a rolling, changing system. Changing things as I go. I don’t archive anything or keep past assignments. Really I want the organizations to be a current, live version only.
All the assignments are public—all the time. I make it clear which assignments they should be working on each week.
I change and update all the repos as the class progresses—they are only “ready” maybe a week before the class starts.
For my student repos, I don’t house the repos for the students in a common organization. Only the learning materials and assignments are in the course’s organization. The students each have their own free GitHub account & fork the assignments into their own account—which are all public. So, they’re free to manage/delete the repos whenever they want.
Thanks for the input so far, this is quite useful. For my purposes, perhaps the possibility of having separate organisations for each year may be most suitable. Our students become quite capable in GitHub over the semester, but I still worry that they would have problems with searching for lessons/exercises if too many future repositories are visible (i.e., @thomasjbradley’s approach). I already have some issues with the students getting confused and forking exercise repositories rather than using their private repos created within the organisation using GitHub Classroom.
Like many of you, I like to keep all of the learning materials public, so perhaps the separate organisations route would work nicely. That said, I’d be happy to hear about other approaches to this issue .
In our case (I manage two courses where we use GitHub for lab exercise, and also for student group work), we use different Organizations every new year.
It takes a bit of pull/modify/push workflow on our side, but it keeps things cleaner for the students.
We don’t use Classroom, since when we tested it, it didn’t work reliably. It might have improved, though, I haven’t rechecked recently.
We instruct students to fork the assignment into their own repository. If they need feedback on their work, they’ll just send us the link to their work, and we review it.
I’ve used GitLab in the past years but this schoolyear I’m focusing on a chat-based teaching style with Gitter and GitHub. Gitter-chat is used quite intensely - mainly during in-class-hours - for assignments, tips, pictures (live demo screenshots), links, … Every student has their own workstation to participate.
Sometimes I use Assignment-Repo’s but there is also the Course-Repo which is mainly edited after class-hours (mainly because my courseware is still being converted to GitHub).
In the Course-Repo there is a
README.md which contains ALL the links to little courseware-snippets. These snippets are roughly organised by topic in subdirectories. They are to be read, re-read and practiced regularly by students. Each snippet ideally focuses on one syntactic and/or conceptual skill (like a for-loop, an array, … - I teach programming). The
README.md provides a kind of chronological/topical index: a starting-point for regular practice.
I am thinking about using these techniques in the (near) future:
- In the README-index, each link can include an emoticon (, , …) to show which topics are new or have to be focused on during a single session. The commits with the emoticons can be updated live in the beginning of a lesson but also weekly (for the bigger picture). These emoticon-commits can be kept in separate, temporary branches (removed biyearly for example). They track the course-progress.
- pupils must fork the Course-Repo to make their own note-commits. These notes can be shared with the teacher, should the need arise. (For now, I’m letting students make a little portfolio-repo with their own notes.)