• Coordination: Issues
• Collaboration: Pull Requests
• Communication: Discussions

All activity lives under the Course GitHub org.

• Private course repository: where all development happens during Spring 2026.
• Public AuditZoo repository: the upstream open-source version.

At the end of the semester, if a student or team is happy with open-sourcing their work, we will coordinate merging their project into the public repo. Students are welcome to continue contributing after the course.

Branches are the basic mechanism that allows safe parallel development. (GitHub Docs)

Rule:

• Each student or team works on their own branch in the private repo.
• You should sync with main at least weekly.
• Naming convention: team-name/proposal-name.

Why weekly sync matters:

• AuditZoo is under active maintenance, and your work will break less if you pull changes regularly.
• It reduces last-minute integration conflicts before deadlines.

Keeping your work up-to-date:

Option A (common and simple): Keep your PR up to date with the base branch using GitHub's "Update branch" controls. (GitHub Docs)

Option B (using git locally): Fetch and merge changes from the remote repository. (GitHub Docs)

The course does not require one specific method, but it does require the outcome: your branch should not drift far from main.

• All changes that should land in main go through a Pull Request.
• Open PRs in the course repository.
• PRs during the course are mainly for feature and infrastructure improvements.
• Track B projects should merge more frequently to stay in sync with fast-moving infrastructure.
• PRs make it easy to reference what changed during development.

• Infra tasks and integration requests.
• Bug bounty submissions (in a structured way, typically kept private until disclosure is appropriate).

Please open issues in the private repo. We will maintain a few templates to keep triage fast:

• Feature Request
• Bug Report
• Integration or Build Help

1. One paper sign-up Discussion (single thread): Students claim presentation dates and slots there.
2. One proposal Discussion per team: Each team creates a dedicated Discussion for their project proposal and updates.

This keeps GitHub communication useful without turning it into weekly paperwork.

Discussions live in the private repo.

Every claimed bug needs a GitHub issue in our repo to notify us. See the bug bounty leaderboard for updates.

• Target repo link and evidence it has at least 1000 stars (or is clearly well-known).
• Link to maintainer confirmation (issue comment, accepted PR, security advisory acknowledgement, or similar).
• Short description of the vulnerability class and where it occurs.
• Team name so points are attributed correctly.