KUCODE

Making GitHub Activity Useful Beyond the Classroom

Code and collaboration histories live on GitHub, but a repository alone does not explain which course a project belongs to or who contributed to it. Faculty and teaching assistants needed a course-level view, while students needed material to explain their own experience.

KUCODE serves both purposes. It connects students’ GitHub accounts with academic records for educational analytics and turns that activity into e-Profiles and portfolio material. As a research assistant and PM, I led the project and worked across the Django backend, Vue.js frontend, and deployment infrastructure.

A Data Structure Connecting 1,000+ Students, 30 Courses, and 9,000+ Repositories

Collecting GitHub accounts is not enough to compare activity across courses. The same course can have different students and projects each year, semester, and section. We modeled courses, registrations, and project repositories separately, with explicit relationships between them.

GitHub IDs link development activity to students; year, semester, and course code identify each offering. Enrollment and course–project relationships remain separate, supporting both course-level views and accumulated activity for students who take multiple courses.

A team repository’s total commits should not be presented as one student’s contribution. Commit, PR, and issue authors are stored alongside contributor records so the e-Profile can show that student’s own activity. It also distinguishes owned repositories from contributions to other repositories.

Syncing Only Changed Repositories Instead of Recollecting Everything

The service links 9,095 repositories to student accounts. Collecting all their activity on every run would repeat API calls and writes for unchanged data. The current synchronization path compares repository update and push timestamps, reusing each owner’s repository listing within a run.

Push timestamps alone are not enough. PRs and issues can be created or change state without a code push. Even when repository metadata appears unchanged, the collector checks PR and issue activity separately and includes repositories that need refreshing.

A failed activity check does not remove a repository from the collection list. Treating a failed request as “no change” could miss real activity, so the implementation accepts extra collection work when the result is uncertain. A full-sync path remains available, and a repository–SHA uniqueness constraint prevents duplicate commit records.

Course-level GitHub Activity Without Opening Repositories One by One

Faculty and TAs can view enrollment alongside commits, PRs, issues, stars, and repository counts without opening each repository. Academic records and development activity appear together, with course and department filters in the analytics screens.

Roster import, search, and statistics export support educational workflows. Course management shows offerings by term, while student analytics links enrollment with GitHub activity, making it possible to trace participation back to a student and course.

Collection is separate from page requests, so these views use stored data rather than waiting for GitHub each time. The student–course analytics endpoint preloads enrollment and course relationships and groups repositories and projects by ID, reducing repeated relationship lookups inside student and course loops.

Turning Collected GitHub Activity into Student e-Profiles and Portfolios

The collected data is not limited to an administrative dashboard. Each student’s e-Profile combines languages, commits, PRs, issues, activity trends, and projects, alongside an introduction and technology stack.

Students can review coursework and independent activity separately, then select which projects to include in a PDF. This lets them choose experience relevant to an application instead of exporting every repository. Activity metrics provide evidence for a project story; they are not a standalone assessment of ability.

KUCODE Owned from Planning Through Development and Operations

As project lead and PM, I worked from the development plan and screen specifications through full-stack implementation and infrastructure setup. The same data had to support students presenting their experience and faculty reviewing course activity, with different scopes and purposes for each view.

The service uses Django, Vue.js, and PostgreSQL, with Nginx and Gunicorn deployed through Docker Compose. Separate Compose projects and data volumes keep local and staging changes apart from production data and configuration.

KUCODE now holds data for 30 course offerings across 5 semesters. Connecting GitHub activity to academic records made that data useful both to faculty reviewing educational activity and to students building a record of their project experience.