To support teachers who want to master GitHub, we’ve launched Campus Advisors—a training program built to help you commit with confidence and teach your students with real-world tools.
Our inspiration for the training comes from the teachers in the Education Community who innovate in their courses, help each other with recommendations, and contribute to open source projects.
The teachers out there never fail to amaze us. We’ve seen Taichi Furuhashi build a GIS course support Red Cross relief efforts, Mine Çetinkaya-Rundel use open source to nurture reproducible research, Dan Wallach contribute scripts back to the community, and so many more examples of teachers doing impactful work. We’ve worked with hundreds of these passionate educators to create the curriculum for GitHub Campus Advisors.
Over the past few years we’ve seen version control take hold in statistics, biology, ecology, libraries, and journalism departments, in addition to a becoming a standard in computer science and engineering courses.
One of the most common questions we hear from these teachers is “How do I use Git and GitHub?” We’ve seen the magical things that teachers do with GitHub, and we want to help.
The Campus Advisors training directly addresses classroom use and the needs of teachers in four modules:
All of these modules are online and available fo you to take at your own pace. Once you complete the last exercise, you can apply to become a certified GitHub Campus Advisor.
As a GitHub Campus Advisor, you’re not only an expert in Git and GitHub. You also champion the use of real-world tools at your school and help teachers new to GitHub use version control.
If you’re passionate about implementing new technologies at your school, or active in your continuing education community, get certified as a GitHub Campus Advisor and we’ll equip you with workshop materials, and custom goodies to show the world your expertise.
Special thanks to all of the teachers who weighed in with the 2017 classroom survey, the folks who gave feedback at GitHub Universe: Teacher Day, and the teachers and librarians at Duke University who tested the curriculum in-person.
In the third programming course in the computer science major, Dan Wallach wants students to master programming in Java with a high degree of rigor and at a large scale. This past semester in his Comp215 course, he chose to use Java8, IntelliJ, and GitHub to implement a test-driven development workflow.
Wallach sees three supporting “ladders” at work in his curricula: Java programming, software design, and tools like Checkstyle, Error Prone, Gradle, and GitHub.
Wallach encourages his students to focus less on specific tools and more on their fundamentals. “I want to teach ideas and concepts that’ll have a long shelf life. So 10 years from now, is IntelliJ going to be the thing? Is Java even going to be the thing? Probably not,” he said. “But mapping a function over a list to get another list, that will be there 10 years from now.”
Dan was looking for a scalable, reliable solution for his course: In 2015 the peak loads from his students’ work crashed their campus Subversion server, forcing them to extend their deadlines and ultimately run a private server, requiring significant assistance from Rice’s IT group.
He decided to move to GitHub and use GitHub Classroom in the fall of 2017.
I had confidence that GitHub would make sure their service would be up and available. Their commercial business depends on high uptime.
Dan used GitHub Classroom, a teacher-facing tool that enables the GitHub workflow for courses, to distribute assignments, and Travis CI to run unit tests.
I was initially worried that the complexity of Git would be a pain point for my students. As an example, I was afraid of having to explain to a student what a “detached HEAD state” might be. In practice, this was never an issue. We steered students to using IntelliJ’s front-end for Git, keeping them from getting into too much trouble. It’s a nice bonus that students can visit the web page for their repo and double-check that everything was correctly pushed.
An example of distributing an assignment through GitHub Classroom and tests through Travis CI.
As the semester progresses, his students get better at “filling in holes,” Wallach said. Initially, Wallach provides his students with code that has missing pieces.
After they fill in those holes with their own code, he introduces a more complex activity: Build an application from the library of code they’ve previously helped build.
“Every week builds on the previous week. I give you a bunch of code including a correct implementation of the prior week’s project, you write tests and add missing features, and then you submit it,” he explained.
Wallach has what he calls a “controversial” position on pair programming: He doesn’t use it in his classroom. He sees pairing as only one path to collaboration.
“Learning to use Git, from scratch, is hard enough without collaboration,” he said. He’d seen his students try to pair while learning Git:
“Hey, you didn’t push your changes.” “What? Yes, I did.” “Okay, now I’ve got a merge conflict.”
While that back and forth is a kind of collaboration, Wallach wants to set students up for success.
There’s plenty enough to learn about version control systems in a solo environment. Comp215 is many of our students’ first experience using development tools on their own computer, as opposed to in a browser. Partner-based collaboration with Git requires a more sophisticated understanding to deal with merge conflicts, pull requests, and so forth.
By having his students work by themselves first, Wallach prepares them with the habits and mental models for subsequent classes in the curriculum where they work in teams.
Wallach built several scripts to help with his class workflow and shared them with the GitHub Education community. For example, Git takes its commit times from the clock on the students’ computers. When Wallach spotted a student attempting to use this to submit after a deadline—using his Travis CI/GitHub workflow which logs the time on Travis and cannot be forged by a student—he made a tool to produce a nice table with a given student’s commit times and GitHub’s push time.
Wallach encourages collaboration through his GitHub contributions and his classroom. And his groundwork has paid off. He often hears from past students that his class prepared them for a workplace environment. By teaching skills that have a long shelf life, Wallach’s students feel ready to collaborate in the long term.
Here are some of Wallach’s helpful contributions to the GitHub Classroom community of tools:
Wilhelm Klopp is a student at University College London (UCL), a Campus Expert, and creator of Simple Poll—one of the most popular Slack integrations. He spent the summer of 2017 as a Developer Relations Intern on the GitHub Education team. In this post Wilhelm shares his work on GitHub Field Day over nine weeks at GitHub HQ in San Francisco.
At UCL, our student community is vibrant and engaged, but after a few years, I noticed that we lacked a system for “knowledge transfer”, including a way for older leaders to train new students before they graduate. There are a few great resources out there to help solve this problem. Campus Experts, for example, is an online training community to enrich the technical community on your campus.
Personally, I was interested in developing an in-person event for student tech leaders—and GitHub Education was interested, too. For my internship, I proposed to start with a prototype event at GitHub HQ in San Francisco, and grow it to wider scale from there.
The event, later called “GitHub Field Day,” would bring together tech student leaders to learn from each others successes and mistakes, figure out what works and what doesn’t in community development, and get to know each other. Field Day would be an event where students create an agenda of their pain points and success stories. After a day of learning from each other, they could go back to their own schools and apply the lessons learned.
The first week as a GitHub intern is big—kind of like moving to new city and starting a full-time job. You move into a flat in San Francisco, meet your co-workers, and get to know the team you’ll be spending time with over the summer. The Developer Relations interns also got to join the Education team for a “mini-summit”: a twice-annual team meeting where we discuss priorities and timelines, while getting a sense of how the team works together.
Something that not very many people know about GitHub is that over 60 percent of its employees work remotely. Although all interns are based in San Francisco, we worked remotely with our GitHub team members—sometimes across multiple time zones. This can be challenging at first as you learn to use a plethora of communication tools to their fullest.
For example, if your teammate lives in Scotland and you’re in San Francisco, you might get a few Slack messages outside of working hours—or even wake up to reminders about 4 am meetings.
Interns have on-boarding cohort, just like GitHubbers do–and complete with swag. Here’s the whole internship class in our navy GitHub Intern hoodies.
Fellow interns @jasonetco and @kim-codes and I worked quickly to gear up for a successful launch, which meant we needed branding, an announcement, and a landing page for the event. Together, we managed to get it all up and running in just five days. The morning of the event, we also put together banners, name tags, and enough food to feed dozens of students.
The hard work paid off: We received hundreds of applications from students who wanted to improve their communities, and on Field Day we had a packed house. When 50 students began to walk through the door, I knew we were onto something great—everyone was excited and had a lot to talk about.
One topic was learning design for coding beginners, particularly relevant to student-run events and hackathons. Another common pain point was how to develop a group identity, and make new members of a school’s tech community feel like they belong. Students also wanted to be able to connect their campus community with other schools, something they could accomplish through the relationships they built on Field Day. We even had a surprise visit from GitHub’s Senior Vice President of Technology, @jasoncwarner who did an impromptu Q&A.
I’m happy to share that Field Day lives on: all the work going into the branding, outreach, design and reflection has now shipped to 10 scheduled events around the world.
Thanks to my awesome intern cohort and especially @kim-codes—my partner-intern in crime in brainstorming, ideation, and execution.
We’re just wrapping up application season for our 2018 internships. If you’d like learn more or get updates on recruiting for our 2019 intern cohort, visit internships.github.com.
How many students can help solve urgent problems within weeks of writing their first lines of code?
In Taichi Furuhashi’s “Introduction to Spatial Information Systems I” at Aoyama Gakuin University in Japan, students collaborate with organizations like the American Red Cross, the World Bank, the United Nations and the Japan International Cooperation Agency.
For Furuhashi, President of CrisisMappers Japan, student engagement and active learning are his primary design principles. The relatively new program helps students work together to make new tools that solve big problems.
Furuhashi’s courses have been dedicated to alleviating disasters, and his students work on different aspects of providing accurate and up-to-the-minute data to aid in relief to NGOs and industry partners.
Design principles behind the School of Global Studies and Collaboration.
In July of 2017 the Asakura City region of Japan was hit with heavy rains and flooding. Whole sections of southern Japan were impassible, and residents urgently needed resources like water and food.
Organizations like the Red Cross used the Humanitarian OpenStreetMap Team’s tasking manager (called HOT for short) to post requests for analysis of affected regions.
Students in Taichi’s class accept a request for mapping help from the Humanitarian Open Street Map tasking manager (a.k.a. HOT).
Photos of the affected regions come in via probe drone, satellite, or panoramic camera. Students draw polygons on maps that match up with these photos to show affected regions, like mudslides, downed forests, or collapsed bridges. Then they export the GeoJSON data to a GitHub Gist file (like this one) and send the analysis back to organizations the Red Cross via HOT.
This map captures the heavy rain caused by Typhoon No. 3 on June 30, 2007. It’s based on images taken by helicopter by the Ministry of Land, Infrastructure and Transport. The polygons and lines indicate potentially impassable roads due to mudslide and the general reach of the flood.
The contributions that students make—their polygons and data analysis—can help authorities decide where to send resources and find flood and landslide victims. By helping local crises, the work of the class is always relevant and urgent.
As the Director of OpenStreetMap Foundation Japan, Furuhashi involves students directly in the open source communities he’s a part of. This means mastering the GitHub flow, using GitHub Pages to make portfolio sites, and participating in open source communities.
He produced a slide deck to help onboard students to the world of GitHub and introduce them to the world of open source. The slides are, naturally, under an open license: CC BY-SA 4.0.
If you’re looking for a real-world approach to computer science education in Germany, you can find it at the Hasso Plattner Institute (HPI) in Potsdam, which offers a practical and engineering-oriented alternative to conventional computer science programs.
In one of HPI’s undergraduate software engineering courses, researchers Arian Treffer and Christoph Matthies encourage their students to make mistakes, assess where they get stuck, and reflect on their software development process. This way students learn how to deliver the best possible results when working together.
The final year undergraduate course “Software Engineering II” features a real-world software development challenge: 20-30 participants jointly develop a single system. Students form small development teams and coordinate within as well as with the other student’s teams. Tutoring, lectures and an introductory exercise are offered alongside the project. All code is published on GitHub under an open source license. Christoph says:
When you leave here, you should have an idea of how to develop software in a team. It’s likely that you’ll work with others on some outdated legacy system in your later work life. As long as people have the ability to reflect on how their process, they are more likely to succeed in whatever they want to do.
Arian adds, “If you don’t practice good communication and you work in a setting with multiple teams, frustration is inevitable. The first time your code is thrown away because someone else has already completed your ticket is an important learning experience.”
Focusing on communication and self-organization shapes how students start coding: commit often, write clear commit messages, and learn from your mistakes. But first, students learn the basic tools and processes needed in an introductory exercise. However, managing these exercises for many students—and checking them manually—can get tedious.
Professor CI introduces students to technical tools using GitHub’s continuous integration services.
Participants work on their own repositories in Github and receive feedback and new challenges from the CI server when they push their code.
Arian is quick to note that using CI to help students fix their problems isn’t completely novel. The innovation, he says, is in how they use Professor CI with GitHub.
What is novel is using GitHub issues to motivate people and basically get them into the habit of tackling issues, writing tests and fixing bugs. If an Issue is done, you’re automatically sent another one that progresses the exercise—this is the new part. Prof. CI simulates a customer requesting new features, changes and bugfixes.
Summary of time from acceptance to completion of student tasks via Professor CI. For more details on the design and implementation, see the corresponding paper.
With Professor CI, students can work on their local machines, using their local development tools, and get the benefit of quick feedback from instructors. In turn, instructors have insight into students’ processes and code.
Christoph adds, “Automation is great for standardized exercises, but in the actual development project that follows, we rely heavily on human interaction.”
Building software in teams requires talking to real humans, so the next step in the course is gathering clear and concrete requirements from a stakeholder. As anyone who builds software knows, that’s easier said than done.
Instead of giving students clear requirements for their final project, Treffer and Matthies assign a co-worker the role of the customer, whose primary job is to—well—be a customer.
He throws ridiculous requirements at the students, and changes his mind constantly. Then the students have to get out of the customer what to build. They don’t get requirements. And the development process and all of its artifacts, they have to manage on their own.
This approach ensures that budding engineers get the close-to-real-world experience that the HPI hopes to instill. They develop real skills in listening, negotiating, and communicating that will help them code solid products and reduce wasted effort, wherever their degree takes them.
Treffer notes that students often think that development is chugging along better than it is, because they don’t yet have the experience required to identify problems as they arise. Milestones serve as natural points of reflection at which the group can work together to make processes better. They also closely monitor students, both with tutors and using GitHub tools to make sure they don’t deviate too much from development best practices.
Treffer and Matthies use a variety of exercises that help students find out what worked, what didn’t, and how to make next time better. The Sailboat is an exercise that students use to reflect on the development process.
In this exercise, the sun is what went right and the wind is what pushed the team in the right direction. The anchor represents what slowed the team down, and the rocks, of course, are potential future problems. Marking each feature of the boat scene allows the group to candidly diagnose how they work together.
Reflection exercises allow the students to get closer to one another and their professors to more intimately understand their students. Being able to collectively analyze and discuss what went right and what went wrong allows for some resolution to what might have been a rough sail. It also helps students learn how to collectively develop a process that will, ultimately, create better software and more efficient development time with minimal waste.
Basically, the most important aspect of our lecture is that students learn to apply what they’re doing to identifying problems with their development process and learn how to improve the process. It’s about figuring out which process works best for your team and context.