This will be your first opportunity to collaborate with the other fellows in your Pod on a software project and put some of what you’ve been learning into practice!
You’ll use Git & GitHub best practices to build an Open Source project.
Open Source Fellows:
Your project will utilize at least one of the technologies that your Pod will be contributing to during the program. Ask your Pod Leader for help if you’re unsure.
GitHub Externship Fellows:
Your project will utilize some of the technologies you might encounter during the program while working on your partner projects. Ask your Pod Leader for help if you’re unsure.
By the end of this session, you should accomplish the following:
Familiarized yourself with at least one of the technologies you might use during the program
Practiced collaborating on a project on GitHub using best practices
Expanded your network by collaborating with fellows from your Pod
The Orientation Hackathon takes place during your first week of the fellowship. The kickoff will take place at the end of your first Pod meeting and demos will take place at the beginning of your first meeting during your second week.
Orientation Hackathon Kickoff – During this event, we’ll reveal the “secret ingredient” (your Pod’s assigned projects) and help you form teams of 2-3 fellows. Explorer Fellows will work with their Pod Leader to decide what their portfolio platform will do.
Hacking – Between the end of your orientation hackathon kickoff and the beginning of the demos on Monday, you should be collaborating with your team on your hackathon project. Explorer Fellows, you will begin the project in the middle of the week.
Hackathon Pod Demos – All of your Pod Leader's Pods will come together to show off their projects during a series of live demos on Zoom. Judging will take place independently.
As you know, you have until the beginning of your hackathon demos to work on your project. As part of your submission, you’ll need to complete the following:
Publish your project on GitHub with an appropriate Open Source license
Record a 3-5 minute video overview and demo of your project.
Publishing Your Project on GitHub
Before demos the repository should be set to public and should have an appropriate README and LICENSE included. One of the criteria that you will be evaluated on is your use of Git and GitHub best practices, so also try to make sure your commit history is visible on the repository.
Recording Your Video Demo
A day or so before the Demos you should plan to record a video demo of your project. While you’ll do a live demo with your Pod, the videos will be shared with the full fellowship, and the judges for the global competition will see the videos from the top team from each Pod.
During this video demo (and probably your live demo too) you should aim to cover the following key pieces of information.
Project Name & Tagline - The name of your project and a 1-2 sentence tagline describing it.
Project Overview – A more detailed written description of the project. Aim for 3-5 paragraphs about the problem you were trying to solve, how you approached it, and what you built.
Techonologies Used – A list of any technologies you used when building the project, including any not officially being supported by your Pod.
Pod Number and Team Member Names – Your Pod’s number and a list of your team members.
Full page can be found here.
Top Team from each pod
Each team member will receive an Amazon Echo Dot and MLH Swag
Submitting to this hackathon could earn you:
How technically impressive was the hack? Was the technical problem the team tackled difficult? Did it use a particularly clever technique or did it use many different components? Did the technology involved make you go "Wow"?
Did the team put thought into the user experience? How well designed is the interface? For a website, this might be about how beautiful the CSS or graphics are. For a hardware project, it might be more about how good the human-computer interaction is?
Does the hack work? Did the team achieve everything they wanted?
Did the team stretch themselves? Did they try to learn something new? If a team which always does virtual reality projects decides to switch up and try doing a mobile app instead, that exploration should be rewarded.
Did the team apply the best practices including, but not limited to, use of branches, pull requests, reviewing each other’s code, writing a comprehensive README, and using issues to track tasks.