The GitHub Blog

Not every team manages their work on GitHub in the same way. Now you can disable Projects on a repository if you're not using them.

Users with admin privileges can disable Projects by navigating to a repository's settings and unchecking the "Projects" box. This hides the Projects tab from the repository navigation and removes Projects from Issue and Pull request sidebars, as well as Issue timeline events. Disabled projects are also inaccessible via API requests. Projects can be re-enabled at any time, at which point all projects in the repository will be restored to the state they were in when disabled.

Check out the documentation and the Projects API page to learn more.

At GitHub, we recognize that running a great business over the long term requires a measure of "work/life balance" – and that includes recognizing that developers and other knowledge workers have creative lives outside of work. Whether that free time creativity involves contributing to open source projects, art, or activism, we want to encourage our employees, not put up legal barriers. We've codified this approach in our employee intellectual property (IP) agreement. We've made this agreement reusable and have open sourced as the Balanced Employee Intellectual Property Agreement.

By making the agreement an open source project, we hope to lower barriers to and learn more about innovation in this space. The project FAQ includes further background on related law, policies, and projects. Pull requests are welcome.

If you're in the tech industry, you've probably come across some version of an employee IP agreement before. Typically they assign control over your creativity to your employer, to the extent law allows – sometimes even after you've left a job, through non-compete covenants. These agreements and underlying laws impact worker mobility, innovation, and regional competitiveness. Most non-compete covenants are not enforceable in California, which researchers have long cited as a key reason the computer industry took off in California instead of another contender such as Massachusetts.

GitHub's employment agreement goes a bit further than the California default (and applies to employees outside of California). If you're a GitHub employee, you maintain control over your creation unless it is something "you create, or help create as its employee or contractor" and it is "related to an existing or prospective Company product or service at the time you developed, invented, or created it" or "developed for use by the Company" or "developed or promoted with existing Company IP or with the Company's endorsement." It doesn't matter whether you've used company equipment or not.

Sound interesting? We're always hiring, or we would love to see you start taking the same approach at your company. Check out the repository to learn more.

A few weeks ago, researchers announced SHAttered, the first collision of the SHA-1 hash function. Starting today, all SHA-1 computations on GitHub.com will detect and reject any Git content that shows evidence of being part of a collision attack. This ensures that GitHub cannot be used as a platform for performing collision attacks against our users.

This fix will also be included in the next patch releases for the supported versions of GitHub Enterprise.

Why does SHA-1 matter to Git?

Git stores all data in "objects." Each object is named after the SHA-1 hash of its contents, and objects refer to each other by their SHA-1 hashes. If two distinct objects have the same hash, this is known as a collision. Git can only store one half of the colliding pair, and when following a link from one object to the colliding hash name, it can't know which object the name was meant to point to.

Two objects colliding accidentally is exceedingly unlikely. If you had five million programmers each generating one commit per second, your chances of generating a single accidental collision before the Sun turns into a red giant and engulfs the Earth is about 50%.

Why do collisions matter for Git's security?

If a Git fetch or push tries to send a colliding object to a repository that already contains the other half of the collision, the receiver can compare the bytes of each object, notice the problem, and reject the new object. Git has implemented this detection since its inception.

However, SHA-1 names can be assigned trust through various mechanisms. For instance, Git allows you to cryptographically sign a commit or tag. Doing so signs only the commit or tag object itself, which in turn points to other objects containing the actual file data by using their SHA-1 names. A collision in those objects could produce a signature which appears valid, but which points to different data than the signer intended. In such an attack the signer only sees one half of the collision, and the victim sees the other half.

What would a collision attack against Git look like?

The recent attack cannot generate a collision against an existing object. It can only generate a colliding pair from scratch, where the two halves of the pair are similar but contain a small section of carefully-selected random data that differs.

An attack therefore would look something like this:

1. Generate a colliding pair, where one half looks innocent and the other does something malicious. This is best done with binary files where humans are unlikely to notice the difference between the two halves (the recent attack used PDFs for this purpose).

2. Convince a project to accept your innocent half, and wait for them to sign a tag or commit that contains it.

3. Distribute a copy of the repository with the malicious half (either by breaking into a hosting server and replacing the innocent object on disk, or hosting it elsewhere and asking people to verify its integrity based on the signatures). Anybody verifying the signature will think the contents match what the project owners signed.

How is GitHub protecting against collision attacks?

Generating a collision via brute-force is computationally too expensive, and will remain so for the foreseeable future. The recent attack uses special techniques to exploit weaknesses in the SHA-1 algorithm that find a collision in much less time. These techniques leave a pattern in the bytes which can be detected when computing the SHA-1 of either half of a colliding pair.

GitHub.com now performs this detection for each SHA-1 it computes, and aborts the operation if there is evidence that the object is half of a colliding pair. That prevents attackers from using GitHub to convince a project to accept the "innocent" half of their collision, as well as preventing them from hosting the malicious half.

The actual detection code is open-source and was written by Marc Stevens (whose work is the basis of the SHAttered attack) and Dan Shumow. We are grateful for their work on that project.

Are there Git collisions?

Not yet. Git's object names take into account not only the raw bytes of the files, but also some Git-specific header information. The PDFs provided by the SHAttered researchers collide in their raw bytes, but not when added to a Git repository. The same technique could be used to generate a Git object collision, but like the generation of the original SHAttered PDFs, it would require spending hundreds of thousands of dollars in computation.

What future work is there?

Blocking collisions that pass through GitHub is only the first step. We've already been working with the Git project to include the collision detection library upstream. Future versions of Git will be able to detect and reject colliding halves no matter how they reach the developer: fetching from other hosting sites, applying patches, or generating objects from local data.

The Git project is also developing a plan to transition away from SHA-1 to another, more secure hash algorithm, while minimizing the disruption to existing repository data. As that work matures, we plan to support it on GitHub.

Data science is a melting pot of disciplines: students from Anthropology to Political Science to Education all sign up for the same course. It’s a challenge to keep the material engaging for everyone.

At the same time, teachers want the next generation of data scientists to be able to analyze any dataset they come across in the future with the same level of rigor used in the classroom. That outcome requires a consistent level of training, across diverse datasets.

Mine Çetinkaya-Rundel, Director of Undergraduate Studies and an Associate Professor at Duke University, tackles these problems head-on. She quite literally wrote the book on the subject, and her open, online course Master Statistics with R certifies thousands of students a year. She edits the Citizen Statistician blog and offers the annual Duke DataFest, a hackathon for working with data.

Her data science course emphasizes “reproducible computation”, a documented process of how data is treated in order to replicate the results in the future. She meets that learning goal using R Markdown and R Studio, as well as by requiring students to incrementally commit their changes using Git and GitHub.

Students learn the concept and the real-world tool, at the same time

Some instructional products have a high learning curve in-and-of themselves. Çetinkaya-Rundel would rather students learn a language in the discipline that they can later build upon:

They learn a limited bit of R syntax that allows them to analyze and visualize data in R. While the goal of the course is not to make each student a proficient R programmer, they learn enough R to be able to build on in their second or third classes. Teaching software designed to be used only in an introductory class would not have this benefit.

Editing an R Markdown file in RStudio by Chester Ismay, MIT License

She wants her students to ship their first visualization project quickly and get started “like a knife through butter” without errors. To bootstrap their efforts quickly, she has them access RStudio Pro using her department’s server.

Best practices for scaffolding collaboration

Sta112FS introduces Git on day one to help students learn about version control gradually and in increments. Her GitHub structure is one organization for the course, one repository per team, and one per assignment. She recommends starting out with an individual assignment first, so students can get used to Git’s mental model before adding the complexity of collaboration.

Mine has students access their projects through RStudio, which she integrates with Git. These slides are from her talk, A first-year undergraduate data science course.

On group projects, Mine creates one repository per team, and everyone on the team can push. Knowing that students will encounter merge conflicts when they’re working asynchronously, she provokes the error messages early on in the semester.

In the first exercise, students clone a demo repository and are asked to edit the README in two tools, first on GitHub and then again in the RStudio editor. The conflicting changes throw an error, which she teaches students to resolve calmly, and by reading the messages.

I show them how I would resolve [the conflict], and then they do the same thing... I tried to create a situation in the classroom that could be frustrating for them later, and say, "This is about to happen. It's important to read the message that it sends you, and this is how you would resolve it.”

The setup pays off in engagement and curiosity

For Mine’s course, using a computation tool prompts students to engage with data directly—an important pedagogical choice to make their analysis both personal and real. There’s a freedom in exploring and tinkering with the real-world tool that professionals use.

Using a computational tool means that you can give the dataset to the students, and they can play around with it. They might be playing around with it in a way that you have designed the assignment or the assessment, but still it gives them the flexibility to look at another variable, make a different plot, than what was assigned for them to do.

Git and GitHub expertise after students leave the classroom

While she keeps student repositories private, merely using GitHub gives her students an edge later in their careers. They can also choose to make their repositories public after they are done with the course.

A lot of students have said to me later, even first-year undergraduates, that using GitHub has helped them a lot when they went for an internship or a research position interview.

They are able to say, "Oh, I already have worked with GitHub. I'm familiar with it. I know how it works.” So I think they are at least able to put that on their CVs and go into a situation where there's a research or data analysis team and say, "Yeah, sure. I am actually familiar with the same tools that you use."

Creating RStudio projects from GitHub repositories

To see an example of Git and RStudio in action, check out this tutorial from Dr. Nicholas Reich at UMASS-Amherst:

This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:

• How CS50 at Harvard uses GitHub to teach computer science, featuring David Malan
• GitHub Classroom for AP Computer Science at Naperville North High School, featuring Geoff Schmit
• Real-time feedback for students using continuous integration tools, featuring Omar Shaikh

Join this week’s discussion in the community forum: What are your favorite Statistics/R/ GitHub Resources?

Back in September we added open source licenses to repository overview pages. Now, when you view a repository's license, we'll tell you a bit more about it.

If a project is licensed under a popular open source license like MIT, Apache, or GPL, you'll see a brief description of the license, along with an overview of what you can and can't do with the project.

Interested in incorporating the license metadata in your own project? The license descriptions and metadata are themselves open source, pulled from choosealicense.com and made available via the license API.

We hope the additional license metadata helps you make informed choices, but please keep in mind that we’re not lawyers (at least most of us aren't). If you have any questions regarding the right license for your code or any other legal issues relating to it, of course, it’s always best to consult with a professional.

Happy open source licensing!

Humans need at least 3.5 contribution mugs worth of water every day. This 18-ounce mug can help contribute to even the most demanding of hydration habits. Mix the contribution graph with coffee, tea, water, ice cream, cereal, soup or even your pet goldfish. You decide what goes in the mug, we won't judge. Get the Contribution Mug in the GitHub Shop.

In honor of our Bug Bounty Program's third birthday, we kicked off a promotional bounty period in January and February. In addition to bonus payouts, the scope of the bug bounty was expanded to include GitHub Enterprise. It may come as no surprise that including a new scope meant that the most severe bugs were all related to the newly included target.

There was no shortage of high-quality reports. Picking winners is always tough, but below are the intrepid researchers receiving extra bounties.

First prize

The first prize bonus of $12,000 goes to @jkakavas for their GitHub Enterprise SAML authentication bypass report which allowed an attacker to construct a SAML response that could arbitrarily set the authenticated user account. You can read more about the story on their blog.

Second prize

The second prize bonus of $8,000 goes to @iblue for their remote code execution bug found in the GitHub Enterprise management console. This was due to a static secret mistakenly being used to cryptographically sign the session cookie. The static secret was intended to only be used for testing and development. However, an unrelated change of file permissions prevented the intended (and randomly generated) session secret from being used. By knowing this secret, an attacker could forge a cookie that is deserialized by Marshal.load, leading to remote code execution.

Third prize

The third prize bonus of $5,000 goes to @soby for their report of another GitHub Enterprise SAML authentication bypass. This attack showed it was possible to replay a SAML response to have our SAML implementation use unsigned data in determining which user account was authenticated.

Best report

The best report bonus of $5,000 goes to @orangetw for their report of Server-Side Request Forgery. This report involved chaining together four vulnerabilities to deliver requests to internal services that end up executing attacker-controlled code. The reporter supplied a clear explanation of the problem through each step and included proof-of-concept scripts for the entire journey. While this report did not earn a prize for being the most severe, it is exactly the type of report we want to encourage reporters to submit.

Other notable reports

We received a wonderful Christmas gift from @orangetw with a SQL Injection bug on GitHub Enterprise. You can read more about how they learned Rails in three days before finding the bug.

A theme we've seen continue over the years is paying out for bugs that aren't in our own code but in browsers. 2016 was no exception with @filedescriptor's report of funky Internet Explorer behavior detailing how a triple-encoded host value in a URL is handled in redirects.

Lastly, Unicode gonna Unicode. @jagracy found a way to exploit the way Unicode was normalized in our code and in our database engine to deliver password reset emails to entirely different addresses than what were intended.

Some statistics

Our "Two Years of Bounties" post has detailed stats for our submissions during the first two years of the program. These years saw a total payout of $95,300 across 102 submissions out of a total of 7,050 submissions (1.4% validity rate). So far in the third year of the program, we have paid out for 73 submissions for a total of $81,700. Many of these reports fall into our "$200 thank you" bucket. These are issues that we do not consider severe enough for an immediate fix, but that we still want to reward our researchers for. Forty-eight of these issues were deemed high enough risk to warrant a write-up on https://bounty.github.com. We saw a total of 48 out of 795 valid reports, bringing our validity rate to 6%.

In 2016, we saw a slight decrease in the number of reports compared to the average of the previous two years. While we can't know for certain, we suspect this is due to the ever-decreasing presence of "low hanging fruit." Unfortunately, we saw an increase in the number of "critical" reports. All other categories saw a decrease in the number of reports.

Out of the accepted reports, we saw some notable changes in the type of vulnerability reports submitted. Many categories such as XSS, Injection, and CSRF saw a decrease in reports. Notably, the number of valid CSRF reports for 2016 was zero. At the same time, we saw an increase in session handling bugs, sensitive data exposure, and missing function level access controls.

In April of 2016, we transitioned to the HackerOne platform. The graphs will not include all data for the year, unfortunately, but the data is still interesting. Notably, even though we had run a public bounty for almost 2.4 years, we still experienced a large spike upon announcing the transition, just like many programs' initial public launch.

We've also been able to track new data via the platform. For example, our average response was about 16 hours and our time to resolution was about 28 days. Tracking this data and keeping it within acceptable bounds will help ensure our program continues to run smoothly and efficiently.

It's more than just a bounty

We continue to see rewards being donated to charities. We absolutely love donating bounties, and we match all contributions. This year saw donations to Doctors without Borders and the Electronic Frontier Foundation (EFF).

We also sponsored an event that was aimed at helping people from under-represented backgrounds participate in bug bounties. The h1-415 event saw attendance from groups like Hack the Hood, Women in Security and Privacy (WISP), FemHacks, Lairon College Cyber Patriots, and /dev/color. Hack the Hood was nice enough to make a video from the event.

In 2016, we've learned a lot about running a bug bounty program and we've continued to uncover sharp edges of our services and codebase. Our program will continue to evolve to engage and support the community of bounty hunters that have made this program successful. We look forward to your submission in our fourth year of the program!

Best regards and happy hacking,

@GitHubSecurity

Starting today, all Markdown user content hosted in our website, including user comments, wikis, and .md files in repositories will be parsed and rendered following a formal specification for GitHub Flavored Markdown. We hope that making this spec available will allow third parties to better integrate and preview GFM in their software.

The full details of the specification are available in our Engineering Blog.

This project is based on CommonMark, a joint effort to specify and unify the different Markdown dialects that are currently available. We've updated the original CommonMark spec with formal definitions for the custom Markdown features that are commonly used in GitHub, such as tables, task lists, and autolinking.

Together with the specification, we're also open-sourcing a reference implementation in C, based on the original cmark parser, but with support for all the features that are actively used in GitHub. This is the same implementation we use in our backend.

How will this affect me and my projects?

A lot of care and research has been put into designing the CommonMark spec to make sure it specifies the syntax and semantics of Markdown in a way that represents the existing real-world usage.

Because of this, we expect that the vast majority of Markdown documents on GitHub will not be affected at all by this change. Some documents sporting the most arcane features of Markdown may render differently. Check out our extensive GitHub Engineering blog post for more details on what has changed.

There's a new way to reinforce your team's code reviews. Now you can specify who in your organization can dismiss reviews on a protected branch.

In the last year, we've been updating pull requests with features that help teams give feedback and make sure only the highest quality code makes it into their projects. You can leave, manage, request, and dismiss reviews, as well as protect branches and limit merging rights. With restricted review dismissals, you can also ensure important feedback gets addressed.

Completely remove the ability to dismiss reviews on a protected branch or restrict that ability to a subset of users or teams specified in your branch protection settings for any organization repository.

Git helps millions of developers write and collaborate on code, but it's not always a practical choice for building games. With the GitHub for Unity extension, Unity game developers (artists and programmers alike) can better integrate Git and GitHub into their workflow, even if they're versioning large binary assets.

The GitHub for Unity extension integrates Git and GitHub directly into the Unity Editor. You can easily configure, collaborate, and manage your Git project in a dedicated window. The extension also includes Git LFS v2.0 support to store large binary assets and introduces file locking to help communicate with your team that you are working on difficult-to-merge files.

The GitHub for Unity extension is a first step towards unifying the GitHub and Unity workflows, and we'd love to hear your feedback to help guide us in the right direction. Watch for an alpha release over the next few weeks. We'll be making the project open source and publishing the extension in the Unity asset store soon after.

Many thanks to Emil "AngryAnt" Johansen for all his help in getting this project up and running.

Sign up now to get access to the GitHub for Unity plugin preview.

Today we're announcing the next major release of Git LFS: v2.0.0.

The official release notes have the complete list of all the new features, performance improvements, and more. In the meantime, here's our look at a few of our newest features:

File locking

With Git LFS 2.0.0 you can now lock files that you're actively working on, preventing others from pushing to the Git LFS server until you unlock the files again.

This will prevent merge conflicts as well as lost work on non-mergeable files at the filesystem level. While it may seem to contradict the distributed and parallel nature of Git, file locking is an important part of many software development workflows—particularly for larger teams working with binary assets.

# This tells LFS to track *.tga files and make them lockable.
# They will appear as read-only on the filesystem.
$ git lfs track "*.tga" --lockable

# To acquire the lock and make foo.tga writeable:
$ git lfs lock foo.tga

# foo.tga is now writeable

$ git add foo.tga
$ git commit ...
$ git push

# Once you're ready to stop work, release the file so others can work on it.
$ git lfs unlock foo.tga

Everything else

Git LFS v2.0.0 also comes with a host of other great features, bug fixes, and other changes.

Transfer queue

Our transfer queue, the mechanism responsible for uploading and downloading files, is faster, more efficient, and more resilient to failure.

To dive in, visit our release notes to learn more.

Internals

Git LFS has tremendously improved internals, particularly in Git and filesystem operations. push and pull operations have been optimized to run concurrently with the underlying tree scans necessary to detect LFS objects. Repositories with large trees can begin the push or pull operation immediately, while the tree scan takes place, greatly reducing the amount of time it takes to complete these operations.

The mechanism that scans for files tracked by LFS has been enhanced to ignore directories included in your repository's .gitignore, improving the efficiency of these operations.

In Git LFS v1.5.0, we introduced the process filter (along with changes in Git v2.11) to dramatically improve performance across multiple platforms, thanks to contributions from @larsxschneider.

Thank you

Since its release, Git LFS has benefited from the contributions of 81 members of the open source community. There have been 1,008 pull-requests, 851 of which have been merged into an official release. Git LFS would not be possible without the gracious efforts of our wonderful contributors. Special thanks to @sinbad who contributed to our work on file locking.

What's next?

File locking is an early release, so we're eager to hear your feedback and thoughts on how the feature should work.

In addition, our roadmap is public: comments, questions (and pull requests) are welcomed. To learn more about Git LFS, visit the Git LFS website.

Psst! We also just announced the GitHub plugin for Unity, which brings the GitHub workflow to Unity, including support for Git LFS and file locking. Sign up for early access now.

Today we're introducing a new Business offering that brings SAML single sign-on, automated provisioning and deprovisioning, 24/5 support, and guaranteed uptime to GitHub.com. With direct access to our developer community and growing platform of integrators, teams can scale and work more efficiently using the tools they need. With the new offering, teams can work on GitHub.com or GitHub Enterprise for $21/user/month.

A closer look

These new features build on how development teams already work on GitHub.com: with unlimited private repositories, team and user level permissions, pull requests, code review, and project management tools. Now, they can also access:

• Authentication through SAML single sign-on with support for Ping Identity, Okta, OneLogin, Azure AD, and Shibboleth
• Automated access provisioning and deprovisioning
• 99.95% uptime guarantee
• 24 hours a day, five days a week support with a response time of less than eight hours

You might recognize some of these features from GitHub Enterprise, and you'd be right! By adding them, we hope teams will be able to manage people and tools with added security and efficiency, all while hosting code on GitHub.com. We also expect they'll spend less time on overall administration and be able to grow without the need to manually add users or manage servers.

Teams that need to host GitHub on-premises or in a private cloud can do so with GitHub Enterprise, which has also received a few updates today for performance, reliability, and pull request efficiency. Read more about the latest release.

We'll be covering the specifics of this new offering in an upcoming webcast, along with an overview of how teams use GitHub.

Get started today

If you’re already using GitHub.com to host your projects, you can upgrade through your organization's Settings page. If you'd like to talk to someone first, get in touch with our Sales team—we'd be happy to help you out.

GitHub Enterprise 2.9 is now available with improvements for both developers and administrators. With this release, administrators will see improvements in reliability and developers can get more out of pull requests.

Ready to upgrade? Download GitHub Enterprise 2.9.

Increased reliability and flexibility

Now, with load balancer support, running a load balancer in front of a single GitHub Enterprise appliance or High Availability pair allows for even more reliable deployments.

We’ve also expanded installation flexibility with a new hosting option on Google Compute Engine.

Pull Request enhancements

Starting conversations around code is what Pull Requests and the GitHub Flow are all about. These feature enhancements make that collaboration even more efficient.

• Resolving merge conflicts in the UI — Accomplish more, right from your pull requests, saving you a trip to the command line and helping your team merge pull requests faster.
• Review requests — Request reviewers for your Pull Request from the sidebar, and they will be notified. You can also track requested reviewers and the status of each review.
• Dismiss Pull Request reviews — Remove potential blockers to your team’s progress by dismissing pull request reviews that are no longer valid or are unable to be approved by the reviewer.
• Rebase and merge Pull Requests — Avoid merge commits by using the "Rebase and merge" option on the pull request merge button.

Organization-wide Projects

GitHub Projects can now be used at the Organization level. All users in your Organization will have access to its Projects, so you and your team can plan and manage work across repositories. With Organization-wide Projects, everyone can see what's already in motion and work together without duplicating efforts.

Other improvements

• You can search commit messages using either the main search page or within a repository.
• Creating a new Pages site on GitHub Enterprise is now as easy as 1,2,3.
• Progressively loaded diffs let you to review more changes than ever in one pull request, making large refactor reviews possible in the GitHub UI. Up to 3,000 files will be loaded progressively as you view them, which keeps your reviewing experience comprehensive and responsive.

Upgrade today

Upgrade to GitHub Enterprise 2.9 today to start using these features and keep improving the way your team works. You can also check out the release notes to see what else is new.

For teachers it can be a challenge to get students the help they need exactly when they get stuck, especially in large courses. But when teachers use an automated testing suite like Travis CI with their assignments, students can hone in on their mistakes and iterate to improve.

Students see the value of a test-driven workflow as they are learning, and teachers save time grading assignments: a win for everyone.

Omar Shaikh, Lecturer at San Francisco State University, saw an opportunity to improve the assignment workflow for the C++ course he took over:

"The problem with the manual submission process was that, if a student is missing a small semicolon, or they were almost correct, the TA has no way of knowing because it doesn't compile. Yes, the TA can go into the code and try to grade it, but it's very inefficient."

Build confidence through passing tests

Exercism, a tool that helps code newbies and experienced programmers learn new languages, uses a testing framework to guide students in increments.

“It helps people who are new to programming break down problems into smaller pieces” said Exercism creator Katrina Owen, “a lot of students spent a lot of time being stuck before I introduced test suites. Seeing the green check marks when their tests pass can reassure students that they’ve mastered the skill and the problem is solved for now.”

Experienced Ruby teacher (and TravisCI engineer) Renée Hendricksen agrees: “When you have assignments that are ‘write code to get these tests to pass’ the student gets instant feedback if they are on the right track.”

“When you use a ‘test-first’ teaching method,” she explained, “students get used to reading and understanding errors early. When they start with a failing test, they can look into whether it’s an error because of setup or their application. Let the red-green-refactor guide you.”

Efficient grading for problem sets

Instead of grinding through a lot of time looking for a missing period or semicolon, teachers have insight into exactly which piece of the code didn’t pass and go from there.

For Hendrickson, a testing suite makes grading more efficient because she can see where a student needs help:

“If I see a failing test I can look there immediately and address where they struggled. If all the tests are green, I can focus on working code and give them guidance for style and composition improvement, without getting bogged down explaining syntax issues.”

A step-by-step guide to using tests for immediate feedback

Omar connects his course organization to GitHub Classroom, and then to Travis CI. While there are many ways to implement automated testing, here are the steps to implement his particular workflow:

Step 1: Create the tests

• Make an organization for each class, and apply for the organization discount at the GitHub Education website.
• Prepare homework assignments, their solutions, and test cases. For C++ assignments, Omar used Google's Gtest library for test cases. Create a private repository in the organization, and move homework files there.
• Connect the assignment repository to Travis CI.

Setting up a new individual assignment in GitHub Classroom

Step 2: Make the assignment and connect it to GitHub Classroom

• Omar removes code segments so that students complete them as their homework. He includes a few lines of contextual information as comments embedded in code (such as “Complete this Section”), and creates a public repository with the name of the homework assignment: hwx-template (where x is the homework number).
• Omar navigates over to GitHub Classroom, creates a new individual assignment, and points the assignment to the template repository.
• Omar posts the assignment link from GitHub Classroom to his class forums. As students click on the link, Classroom creates a new private repository for each of them.
• In Travis CI, Omar enables the tests on each of the student repositories. Travis will then build the repository after every push, based on the directions Omar put in the starter code template repository.

Example of a few student repositories on Travis CI for “hw3”

Step 3: Students clone the assignments and complete their homework using the recommended IDE

• Omar uses the CLion C++ IDE from JetBrains, which offers free licenses for educators, and manages Google Tests efficiently.
• Students clone their particular assignment repository with detailed instructions in the README.md.
• Students open the project in the IDE to start coding and running unit tests. As students complete their assignments, they push their changes to GitHub.
• Instructors can see if the build is passing via Travis CI and in the “commit” view on the GitHub web interface.

Graders can look at which tests failed for insight into where students struggle with the material

Use this workflow in your own course

If you’re ready to implement Travis CI and GitHub Classroom, here are some tools to get you started:

• a sample repository you can use as an example with all the moving parts
• a Travis build of that sample
• Omar’s problem sets, which have been tested by his team of teaching assistants and also contain detailed instructions.

To help you put all of the pieces together, Omar made a video walkthrough:

This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:

• How CS50 at Harvard uses GitHub to teach computer science, featuring David Malan
• GitHub Classroom for AP Computer Science at Naperville North High School, featuring Geoff Schmit

Join this week’s discussion in the community forum: How to automatically gather or collect assignments?

Earlier this month, we gave you a preview of our Terms of Service update, and we asked for feedback from our community. You responded overwhelmingly! Thank you so much, everyone who sent us feedback. We heard you, and we have edited the Terms accordingly. The new Terms of Service are now effective!

Your feedback

We received nearly 100 comments on our proposed Terms of Service changes. A few clear themes emerged:

• Positive feedback: Nearly a third of our feedback was very complimentary. Thank you for taking the time to let us know how much you liked the changes.
• Fixed typos: About a tenth of the comments were from users spotting typos. Thanks, we fixed those! (Oops!)
• Refined license grant: We got a good bit of feedback about our license grant section. We certainly understand your concerns, and we've reworded it to narrow the grant and to explain exactly why we're using what we're asking for.
• License agreement for contributors: We also got some feedback about the license under which you contribute to others' repositories. We split that into its own section and clarified the language in it.

Several users asked us to provide a diff of the new Terms compared with the old Terms. We weren't able to, because we wrote the new Terms from the ground up; they were not an iteration of the old Terms. However, we are happy to provide a diff between the February 7 draft and the final draft. Please take a look at the changes you inspired!

The new Terms of Service

Of course, the things you liked about our new Terms are still there. You'll still find:

• Plain English terms: The Terms are still easy to read, with a table of contents for easy navigation, as well as a short summary of each section so you know what you're getting.
• Acceptable Use policy: Our Acceptable Use policy is much easier to read than it was before, and if you want clarification on how we approach that policy, please see our GitHub Community Guidelines.
• GitHub Pages terms: We've got understandable, clear terms for GitHub Pages.
• Advertising on GitHub: Advertising is not prohibited on GitHub, but it is heavily scrutinized because we don’t want to become a spam haven. Our Terms now describe the kind of advertising that GitHub allows.

What this means to you

The new Terms of Service are in effect as of today, February 28. You can accept them by clicking the broadcast announcement on your dashboard or by continuing to use GitHub. Again, thank you so much to our user community! You've helped us make our Terms better. Please let us know if you have any questions about the new Terms, or if we can help you going forward.