University hackathon: a student project submission pack
A template for university hackathon organizers covering project materials, individual contributions, submission deadlines and judge access checks.
·6 min read
What you’ll learn
Review the team project and each student's individual contribution separately.
Collect the code, demo and setup instructions in one submission pack.
Before the deadline, open the pack with the permissions assigned to a judge.
There is half an hour left before the final. One team is replacing its slides, another is trying to get repository access, and a third thought sending the project to the chat would be enough. There is little time to explain the task now. Submission requirements need to be clear to participants, instructors and judges before the hackathon starts.
At Stavleak, we suggest connecting the required materials to the learning objective and the review method. What work will the student submit? How will a judge open it? How will the instructor see what each participant learned? A small pack answering these three questions is enough. Adapt the template below to your university's rules.
First, distinguish two kinds of result
The team project and a student's individual contribution are different things. One experienced participant may build a good prototype. Another student's research or testing may not appear on the final screen. Identify the shared competition materials separately from the individual reflection that shows learning.
If the hackathon counts toward a course grade, the responsible instructor sets the requirements under the university's procedures. Participants need to know in advance which materials are for the competition and which are for academic assessment. Do not automatically turn a team's place in the final into an individual course grade.
Put the submission process on one page
Add these fields at the top of the requirements document:
Submission location: The exact form or project submission page.
Deadline: Date, time and time zone.
Responsible person: The teammate who checks the final pack.
Acceptance indicator: The status or confirmation the team will see.
Editing rules: What can be changed and until when.
Contact for problems: The official channel and the information to provide.
"Send the materials in the evening" is not enough. A record saved in a form may also differ from a submitted project. The organizer should show the actual acceptance indicator and ask participants to check it.
If the deadline changes, notify every team through the same channel. Permission given in a private chat does not replace the shared rules. State which materials the change applies to and when it takes effect.
Pair the required pack with its review method
The list below is for a student hackathon with software projects. If participants submit research, a device or a design, change the materials to suit that result. You do not need to make every item mandatory: do not request a file solely to increase the pack's size if judges will not use it.
Material: Short project description. Contents: Problem, user and working main scenario. Acceptance check: Does the description match the demonstrated result?
Material: Code or other core work. Contents: A reference to the version being assessed and the required access. Acceptance check: Can the judge open the material?
Material: Setup instructions. Contents: Required environment, configuration and verification steps. Acceptance check: Can the reviewer follow them without asking the team for additional help?
Material: Demo. Contents: A working URL or a recording permitted by the rules. Acceptance check: Is the main scenario visible?
Material: Limitations. Contents: Unfinished parts, external dependencies and the data used. Acceptance check: Are the prototype and future plans distinguished?
Material: Team roster. Contents: Participants and their responsibilities. Acceptance check: Does it match the roster in the application?
Material: Individual contribution reflection. Contents: Work completed, decisions made and learning. Acceptance check: Can each student explain their own work?
Attach conditions covering file types, sizes, video length and presentation language to this list. The organizer chooses specific limits based on the submission system and the time available for judging. Do not copy them unchanged from another hackathon.
Ask students to explain their contribution
Do not require students to account for every activity minute by minute. Offer this template instead:
The specific work I completed: ...
A decision I made together with the team: ...
My initial assumption and the test result: ...
What I changed based on the result: ...
A question I still do not understand and my next step: ...
Evidence can be a link to a file, a change, a test result or research notes. Students should not describe themselves as the authors of the entire project when explaining their own contribution. If the work was shared, they should say it was done together.
Do not use commit counts as the sole measure of individual contribution. Investigating a bug, speaking to a user, preparing tests and pair programming leave different traces. An instructor needs to see the student's understanding of a decision as well as the amount of work.
Test judge access in advance
Checking the pack from its author's account is not enough. The organizer should accept a test project and open it with the permissions assigned to a judge. Check the repository, slides, video and demo separately.
Do not require confidential materials to be made public. Agree on the judges' access method in advance. Do not include a student's personal password, a live access token or another person's data in the project description. Prepare safe data and restricted access for the demo.
If an external service fails, state in the rules which alternative will be accepted. Allowing a video does not by itself remove a requirement for a working prototype. The team needs to know which evidence the judge will use.
Preserve the version assessed after the deadline
Identify the version of the accepted materials. If corrections are permitted, apply the same procedure to every team. Silently replacing the original work with a later file makes assessment harder to follow.
If a judge cannot open the materials, the organizer records the issue and follows the procedure published in advance. Keep the contact request, technical check and assessment decision together in one record. This helps explain to the team what happened.
Assessment of learning may continue after the final. Once the project has been reviewed, the instructor can return to the individual reflection and ask the student to explain one decision. Keep the competition score separate from the learning conclusion drawn from that conversation.
Want to host a university hackathon on Stavleak? We can organize the event for you, help with selected stages or provide the event workspace for you to organize it yourself. Start preparing with the organizer materials. Find more guides in the Stavleak resource centre.
