The GitHub Blog

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.

With the the Game Developers Conference (GDC) and Virtual Reality Developers Conference (VRDC) in San Francisco next week, that means it's time for our annual GDC Party.

Please swing by GitHub HQ on Tuesday, February 28th at 7 PM, and feel free to bring your laptops and other devices, show off your games, and meet people who love games as much as you do. We'll supply the drinks, Wi-Fi, and Octocat stickers <3

Our friends from itch.io, Ludum Dare, and the Museum of Digital Art and Entertainment will be there with a collection of fun party games - old school classics, weekend game jam entries, and the latest indie games. We may have one or two surprises too…

Please note: GDC/VRDC badges or proof of registration are required for entry. All ages welcome, but please bring a valid photo ID if you're over 21 and would like to drink. We recommend showing up early to avoid disappointment (we certainly wouldn't be the first GDC party to reach capacity quickly).

Can't make it to the party? We'd still love to meet you. Please swing by booth #2210 in the Expo Hall Wednesday through Friday and say hi!

Many engineering organizations sort developers into teams like application engineering, platform engineering, web development, systems, and quality. Structuring organizations in this way can leave blind spots that exclude the people best qualified to help solve a given problem. To address this blind spot at GitHub, we've tested out a few alternative ways to organize teams by expertise, rather than by application. We refer to these highly specialized groups as ad hoc teams.

What are ad hoc teams?

• GitHub Teams that group people with similar skill sets or interests
• An opt-in social contract to respond to problems in a given domain when called upon
• A vehicle to facilitate developer capability and knowledge growth
• Can be created without administrative intervention
• Variable duration: could be for one problem or long-running

Why use ad hoc teams?

It is rare for a problem to be uniquely applicable to any one application team. Members of several other teams may be better qualified to solve a given problem. Additionally, when a problem is overwhelming to the team primarily responsible for a solution they are often left with few options for help. Why let these common issues stop you from getting the job done when you can organize folks across formal teams into highly specialized problem solving forces?

How do ad hoc teams work?

Imagine a scary situation where a security vulnerability in a JavaScript application has opened up your SQL database to malicious actors. Who would you call for help? While the application may belong to a specific project team, high profile issues like these are everybody's problem. You can immediately get more eyes on the issue by @mentioning teams that might be able to help. This may include your JavaScript developers, SQL experts, and the security team.

The image below illustrates how ad hoc teams can leverage the expertise of multiple members on different teams to solve a single problem.

If devGroupA owns the application, @mentioning all three function-oriented teams helps them reach several people who are members of all three teams but not part of their formal group. This increases devGroupA's problem-solving capacity, puts more eyes on the issue, and results in a faster solution.

Meanwhile at GitHub

We've applied this concept internally with an enterprise-scaling team made of Hubbers that design, build, support, and sell GitHub Enterprise. We encourage folks to @mention this team whenever a customer is planning to scale up their use of GitHub in any aspect. Team members also happily @mention the whole crew whenever interesting threads pass their way. Through this team we've been able to spread information from multiple perspectives to those consulting directly with GitHub customers without scheduling meetings with everyone synchronously present.

What benefits should be expected?

• Better support teams with escalation paths for common engineering issues.
• Resolve problems more quickly by involving the experts when you need them most. No need to wait until tomorrow's stand-up meeting.
• Uncover underutilized known and unknown talents.
• Get fresh perspectives, challenge assumptions, and thwart groupthink.
• Share knowledge when problem domain experts see an issue differently than application experts.

In conclusion

Give "ad hoc" teams a try in your organization and let your problems be solved!

How does Harvard's largest course, an Introduction to Computer Science, use GitHub to achieve its learning goals?

Professor David J. Malan, Gordon McKay Professor of the Practice of Computer Science at Harvard University, is dedicated to offering his students a robust learning experience. This post outlines how he uses GitHub and his own custom tools to build hands-on assignments for CS50 students.

With over 700 students, 80 staffers, and 2,200 participants in their end-of-term CS50 Fairs, CS50 has a reputation for rigor, real-life application, and engaging material.

At the same time, says Professor Malan, about half of CS50’s students typically treat the course as “terminal”— as their one and only course in computer science. So the projects touch on applications in a variety of fields, from social sciences and humanities to medicine and finance.

Malan says of the learning goals of CS50: “We want to provide students with a solid foundation in computer science so that they are well prepared for any field. And also bring to bear some practical skills to that world. So that is actually tied in with our adoption of GitHub this past year.”

A gentle onboarding to Git and GitHub

The mental model for cloning, branching, opening pull requests, or pushing can be tricky for newbies just starting out. As a way to onboard students, Malan wrote a command-line tool that wraps a sequence of Git commands called submit50. They developed submit50 to not “reinvent the wheel” with a new submission system, but to create space for students to grow into comprehensive GitHub use as their learning evolves beyond CS50. Says Malan:

One goal was to have students graduate, so to speak, from the class actually having a GitHub account. And even though they don't keep their work in public portfolios for the course, the hope is that they'll have at least enough understanding of GitHub that they can use it after the term ends for personal projects.

Student workflow for submit50

CS50 uses the structure of one branch per problem, and students engage Git and GitHub from the command line.

First, they run a command in their directory on a Linux system with a folder they wish to submit to CS50’s servers. The student then runs submit50 foo where foo is the unique identifier for that assignment.

submit50 models how Git and GitHub work while abstracting away some of the complexity:

Behind the scenes we show them the command so that through a bit of osmosis, they can infer what's actually going on.

We clone their repo, which lives in our submit50 organization. So we have full administrative rights, and students have push and pull privileges only.

The submit50 script clones that repo into a temporary directory. We do the equivalent of rm -rf to blow away whatever is currently in there, and then git-add the entire contents of their current working directory into that repo, and then tag it with a tag that corresponds to the problem's name, and then push it to the server.

Project-based assignments, real-life applications

An example assignment is “C$50 Finance” where students build an application to simulate stock trades using Python with Flask, HTML, CSS and SQL.

Students create tables with user accounts, who can then buy and sell stocks. The application queries Yahoo Finance for stock quotes, almost in real time.

Malan is delighted to see the different personal touches students add to their projects, both functional and aesthetic.

It's a fun opportunity to introduce students to even the aesthetics of web design. Invariably the first thing students do is customize the aesthetics of the site, and then certainly there are differences in features, and we're fine with that. The assignment requires ultimately that they add a personal touch, so any feature that's not been enumerated by us they're welcome to do so long as it's of reasonable scope. So we'll get different outputs from that as well.

Rituals of success

All students exhibit their final projects an end-of-semester “CS50 Fair.” About 2,200 people attend to see the student demos.

Malan designs the event as a kind of celebration, a capstone ritual where students can show people what they’ve made:

It's a fun way to delight in how much you've finished, particularly if new to programming just months prior. And it perhaps creates a bit of social pressure too. You know you're going to be showing this not just to your Teaching Fellow, but to your classmates, and you want to be proud of it. And so, hopefully, that incentivizes all the more of a strong finish.

Computer science and tech news = CS50 Live

Pushing beyond the boundaries of the traditional classroom, Malan connects the course materials with the news in a kind of “Daily Show” for technology, called “CS50 Live.”

Malan and the crew of Teaching Fellows take up current events, like Apple’s implementation of OpenSSL with a bug in it, and dig into the code on the show.

Hear more about GitHub and CS50 at SIGCSE

Professor David Malan will present CS50 along with Omar Shaikh (SFSU) and S. Monisha Pulimood (The College of New Jersey) at the Special Interest Group in Computer Science Education of the Association for Computing Machinery (ACM SIGCSE).

"How I Implemented GitHub In My Classroom"
Saturday, March 11
10:45AM-12:00PM
Room: 616/617

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

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

You asked for it and we listened. Let us introduce you to Sticker Pack Five. Collect them all from the GitHub Shop!

Participating in open source can be incredibly rewarding, but it's not always obvious how to make your first contribution, start a new project, or build an active community.

To make your journey easier, we're launching the Open Source Guides, a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to open source.

Open Source Guides are a series of short, approachable guides to help you participate more effectively in open source, whether it's:

• Finding users for your project
• Making your first contribution
• Managing large open source communities
• Improving the workflow of your project

These guides aim to reflect the voice of the community and their years of wisdom and practice. We've focused on the topics we've heard about most, and curated stories from open source contributors across the web.

Want to help improve the guides? The content is open source, so head over to github/open-source-guide to participate in community discussions about best practices.

This week more than 350 Git enthusiasts convened in Brussels for Git Merge 2017, and hundreds more tuned in from around the world via live stream. The conference brought together Git contributors, source control teams, and end-users from around the world for two days of sessions, training, and conversation. All proceeds from ticket sales were donated to the Software Freedom Conservancy in acknowledgement of the excellent work they do to improve and defend free and open source software.

Program highlights

Git Merge stands apart as a conference for the Git community at large, promoting goodwill and dialogue between companies that have a vested interest in the success and progression of Git as a technology and that employ Git core contributors.

Education is a key component of the event—Git Merge kicked off with a full day of workshops for developers of all skill levels led by experts from GitHub and Praqma.

On day two, Software Freedom Conservancy’s Executive Director, Karen Sandler, opened the day with a thoughtful keynote about how free and accessible software is the key to building the future. Speakers from Autodesk, Atlassian, MIT, Microsoft and more took the stage over the course of the day to discuss the future of Git. Among the themes discussed were scaling, extensions, aliasing, and education.

Diversity and inclusion

Ten percent of total conference tickets were allocated for distribution to the Travis Foundation, Rails Girls Brussels and Operation Code. Twenty-five students received discount codes and complimentary tickets.

The venue was outfitted with gender-neutral restrooms and a nursing room.

Thank you

Git Merge wouldn't be possible without the support of our sponsors, who come together to support the Software Freedom Conservancy, improve and develop Git, and to make this event happen year after year.

Recordings of the workshops and sessions will be available in the coming weeks. Git Merge will return in 2018, so keep an eye on Twitter for announcements about dates and locations.

We’re in the process of updating our Terms of Service, and we’d like to get your input on the draft of our new Terms.

Why the change?

In short, our current Terms of Service agreement could do a better job of answering your questions about how our service works. We've heard your feedback, and we're updating our Terms to make them less ambiguous and easier to read so that you know what you’re agreeing to.

An overview of the new Terms

In general, this update lets us do a better job of putting our current business practices in clearer terms for our users. Some of the changes you’ll find in the new Terms of Service:

• Reading the Terms: You’ll find a table of contents, as well as a summary of every section in plain English.
• Acceptable Use: We have clarified our Acceptable Use Policy, including our policy on scraping and misuse of GitHub Users’ personal information.
• Ownership of Content: We don’t claim any ownership rights to the content you upload to GitHub. What’s yours is yours. In the new Terms, however, we have added an explicit license to clarify our right to store and serve it without violating your rights.
• Default Contributor License: To address growing confusion over licensing and contributions to others’ projects, we added a simple default contributor license. If it does not suit your needs, you may add your own Contributor License Agreement to your repository.
• GitHub Pages terms: We have clarified our rules regarding 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.

Taking action

We want your input. Please look over our new Terms, compare them to our old Terms if you want to, and tell us what you think via the new Terms of Service contact form. Let us know if you see anything you think should be different, whether it’s a typo we missed or a rule that might have implications we haven’t thought of.

We’ll leave comments open until 5:00pm (PST) Tuesday, February 21. Then, we’ll take a week to go through your comments, make whatever changes will improve the Terms, and we’ll enact the new Terms on Tuesday, February 28.

We look forward to hearing from you!

To honor our commitment to inclusion, we are launching Inform and Act, a site dedicated to showcasing the work of organizations and projects that promote the free movement of people and ideas—those things that make progress possible. Going forward, we will use this site to communicate our position on social issues and point you to actions you can take to support those most affected.

Our first set of actions is in response to the recent executive order on immigration. We have chosen to support the US Muslim community through a gift of $25,000 to the Council on American-Islamic Relations (CAIR). Please join us and donate to CAIR CA while getting involved in one of the open source projects featured on the site.

Ideas for projects and organizations to feature? Email support@github.com.