Single Organization

I understand that the recommended way to use GitHub Classroom is to make a new organization for each course. Some of my colleagues also use GitHub Classroom and we now use a single organization for all our courses. The organization thus represents our university.

I find this practice much more convenient. Sure, we have to be careful about naming our repositories and assignment prefixes to keep things sane and conflict-free but otherwise, this model makes a lot more sense to me.

Is anybody else doing this? Any thoughts on this? Is there any particular advantage with single-course organizations that you think we will miss out on?

1 Like

Hi @waqarsaleem

For crash courses and training I tend to use the single-org approach you described. This is an example https://github.com/easy-peasy-robotics. I believe, indeed, that it makes much more sense than multiple orgs way.

By contrast, for our school on robotics https://github.com/vvv-school I opted for a mix of the two, where material, tutorials, and starter code (we’ve got many) are hosted on the main org, whereas the assignments are stored in secondary orgs that reflect the particular course and year (vvv17-kinematics, vvv18-dynamics…). This way, we can keep all teachers’ material centralized and at the same time we avoid cluttering the main org with too many assignments. Also, having assignments in separated orgs facilitates the archiving process later on.

Hope you can find this helpful. Anyway, if you’re interested, we’ve prepared a detailed list of steps to set up the school here: https://github.com/vvv-school/vvv-school.github.io/blob/master/instructions/how-to-setup-vvv-school.md.

2 Likes

I wanted to do something like this, but ended up having a separate organization this term. The main is reason is that I have lots of programming problems and students. At the end of the semester I could have as many as a thousand repos. That’s kind of hard to manage in just a single organization over time.

1 Like

I’m curious about your single org setup. How are crash courses and trainings different than the school curriculum on robotics? Just trying to better understand when a single meta organization for multiple classrooms would be preferable over one organization to one classroom.

Hi @femmebot

Timewise, the span of our crash courses and training covers from 2 to 4 days, typically with max 20 participants, whereas the schools we run for post-graduate students (around 30 students per edition) last a couple of weeks at most. Our schools are very intensive with lots of topics and code assignments.

Differently from training and crash courses, we have the need for archiving the schools’ assignments for a possible later retrieval as we give credits on their basis.

I have been always assuming that having starter code and courses material centralized in one organization is very wieldy for us. This is only a matter of - let’s say - personal preference. Any time we launch new training or school, we simply create a specific repository within the organization to host the new edition in terms of accompanying material (e.g. website, wiki, syllabus, events, forum, slides). We mostly take the repo of the previous edition as a template and then we populate the new repo with the necessary modifications.

At this stage, we finally decide whether hosting the assignments in the organization or spawning different classrooms in different organizations. As said before, the choice is based merely on the number of expected assignments (limited for training, huge for schools) and on the requirement of officially storing students’ results. The overhead of managing multiple organizations (required for schools to avoid clutter) is cleary spared with training.

I have converged to this policy for three years by now and it’s been working perfectly for our purpose.

1 Like

The big benefit of doing a new “org” every semester is that your course staff, who do the grading and such, only need to get admin rights to the org for which they’re actually working. It’s generally a good security practice to limit the reach of “powerful” users to what they actually need to do their jobs.

A secondary benefit is that you don’t need to do as much work to ensure the repo names are unique. If you have multiple years of students doing the same exercises, you’ll need to encode the year into the repo name to avoid ambiguities.

3 Likes
© 2017 GitHub, Inc.
with by
GitHub Education