The GitHub Blog

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.

Early bird ticket sales and CFP now open

GitHub Satellite is the European edition of our flagship user and product conference, GitHub Universe. Satellite features two keynotes from GitHub leadership and fourteen breakout sessions from all over the GitHub community. We’ll spend an intensive day in breakout sessions featuring maintainers of open source projects, engineering teams facing unique challenges, and leaders using software to change the way their businesses work.

Register before March 7 to save 100 Euro.

Get Tickets >

Interested in speaking at Satellite?

Our call for proposals is open now until March 3. Don’t miss your chance to share your story with more than 600 GitHub users.

Submit a Proposal >

For information on sponsorship opportunities please email events@github.com.

Google provides some guidance on how to effectively run a Google Summer of Code project but it's not tailored specifically to GitHub's workflow. To set clear expectations for mentors and students here's our ideas on how to successfully participate in Google Summer of Code as a mentor or organization administrator.

The application process

Document project ideas

Make a dedicated file or repository for documenting project ideas and discuss them in issues. The ideas should be things that are going to be useful to your project, would take a maintainer a week or two to complete and you think should take a student between a month and a month and a half to complete. You can populate these from help wanted-labeled issues in your repository. They should be brief enough to stimulate discussion on their implementation but not detailed enough for students to be able to copy-paste any part into their proposal.

For example, the Homebrew project has a repository for these ideas (updated for GSoC 2017).

Strongly encourage students to adopt one of your ideas rather than their own. You have a much better idea than they do on what will be useful, achievable, and mergeable.

Require a merged pull request to your project

Rather than angsting over student technical interviews or their proposals documents you should make your decision primarily on which students (if any) to accept based on a trial of the work you expect from them in the summer: a pull request to your project's repository. Google expects students to get involved in communities so requiring e.g. a one line change in a pull request is more time efficient than any other metric.

In general any established GitHub open source repository should have an easy way for new, aspiring contributors to submit a useful pull request. In Homebrew's case they have a brew audit linting tool where some lints are deliberately left unfixed to give newcomers an opportunity for an easy first pull request.

For example, the Homebrew project's process is documented in their README.

You should not help students any more than any new contributor or provide any more guidance than what's already documented in your project. If they ask for help, point them to the instructions (and consider improving them). If they cannot figure out what other contributors can: they are unfortunately not good candidates for GSoC which requires them to be self-motivated, driven and able to learn independently over the summer.

Provide regular review to student pull requests before the application deadline. Make it clear to the student that the pull request must go through the review process and get merged before you can accept their application. They're in a rush, but you shouldn't be. In respect of time, students shouldn't rush last minute to hit a deadline.

The summer

Favor small pull requests over large ones

This is a good principle in general but not the typical mindset for students who typically do work for a single output that's handed in. Encourage them to split their work up into multiple, regular pull requests over the summer so their pull requests can be more easily reviewed and merged.

For example, see @AnastasiaSulyagina's pull request to remove some duplicated exceptions as part of Homebrew's 2016 GSoC. This was a small change review and a merge followed quickly.

Maintain normal flow

Most of your interactions with your student should look like your interactions with other maintainers and contributors on your project. For example, if you talk with other maintainers on Slack, invite your student and encourage them to ask questions when they have them. If you can talk about things in issue comments and pull request reviews: do that instead of video calls or other private methods of communication so that other maintainers can help provide review and feedback.

Brief, regular check-ins

Have a meeting that you both stick to every week (that neither of you are on vacation) on text (i.e. IM), audio or video chat. Defer to the student's preferences on IM vs. audio/video as they may feel more comfortable communicating over text if English isn't their first language. This should be your chance to see what progress there has been if there's been no public activity. That said, a week with no commits, issue comments, or PR comments is a sign of major concern that you should raise with the student.

Strict failure requirements

As mentioned previously: you should not accept students who have not made a trivial pull-request to your project. Similarly, the focus of the summer should be around pull-requests too. If the student does not have a significant, non-trivial pull request opened by their mid-term: they should fail. If the student does not have a significant, non-trivial pull request merged by the end of the program: they should fail. Again, splitting the work up into multiple pull requests over the summer is vastly preferable to opening pull requests at the last minute.

Like many things in life: strict, no-compromise boundaries may sound harsh but end up being kinder to the student. You can communicate these expectations at the beginning of the program and then they don't need to worry about whether they will pass or fail. This is also a life lesson: many deadlines after graduation are not negotiable and it's better to fail at GSoC than many other things in life.

That seems quite strict?

It does, yes. The requirements above may mean that you're not able to get any students who are good enough for your project or that you need to fail students. This is unfortunate but it's ultimately better for students and much better than having a bad GSoC experience.

For point of comparison while following the above system for the last two years the Homebrew project has always had more good students than mentors available for them, never failed any students, had the majority of students ship major features our users have been happy with and, best of all, had a minority of students become and stay Homebrew maintainers.

Now that you know how to effectively run a Google Summer of Code project on GitHub consider applying as a GSoC organisation before the February 9, 2017 at 17:00 (GMT) deadline and have a great summer!

Projects are a great way to keep your tasks organized on GitHub, and they‘re especially useful when working with a team. To make it easier to keep track of what‘s going on in a Project with lots of people, we‘re introducing the new Project Activity view, a way for you to view a history of all the activity that‘s happened in your project.

If you find that a particular card isn‘t where you left it, it could be because one of your teammates renamed it or moved it to a different column. The Project Activity view can help you track down these changes, so you can figure out exactly what‘s changed since the last time you looked at your Project.

Since we‘ve only recently started recording activity for this feature, your project‘s activity history won‘t go back much before January 27th, 2017. However, you‘ll be able to see any changes to your project after that date. It‘s time to start making history!

In the meantime, you‘re welcome to drop any questions, comments, or feedback about Project Activity into our help form.

Discover networks of similar repositories in a completely new way with Topics. Topics are labels that create subject-based connections between GitHub repositories and let you explore projects by type, technology, and more.

Click on a topic that interests you to find related repositories. Adding topics to your repositories will help other users discover your projects, too.

You may see suggested topics when adding a topic to a public repository. These suggestions are the result of machine learning and natural language processing applied to repository content. We're at the start of this new journey and rejecting suggestions that don't fit well will help us train our model for more meaningful results.

Our Help documentation will show you how Topics works today, and there's more to come. Topics will continue to grow as we learn more from you and better understand GitHub's role in project discovery. We can't wait to see how you use this new feature!

We released GitHub Classroom in fall of 2015 to make it easier for teachers to distribute code and collect assignments on GitHub. In the last year, we've seen it enter the classrooms of thousands of teachers. We're delighted that it's helping students learn STEM subjects and even more excited to share the processes, tips, and tricks educators have built around it.

To kick off a series about educators and classroom practices, we'd like to introduce you to Geoff Schmit, a former engineer for National Instruments. In his tenth year of teaching at Naperville North High School, Geoff seeks to prepare students with the mindset of a creative, ethical engineer who uses real-world tools:

I had a background in source control which I brought with me from my life as a software engineer. I think students should learn about source control before they leave this class. They should have written unit tests before they leave this class. And they should read articles about technology in society and ethics before they leave this class.

He kickstarts his semester with pre-filled repositories—sample code and libraries in GitHub Classroom. Students dive straight in, without the tool getting in the way:

On the first days of school I want them doing turtle graphics in BlueJ. I don't want to worry about setting up the environment and everything. So I'm able to pre-package everything, so they can double-click on it and type some code in, and we'll work.

This is his first year using GitHub Classroom to organize his assignments and gently introduces students to GitHub.

Using Classroom, students click on a single link to create and manage their repositories:

So rather than them having to worry about forking, cloning, and that stuff, they just click on the link to accept the assignment.

With Github Classroom things are so much smoother because it copies the whole assignment into a private repository, which is nice.

To submit their assignment, students commit to the master branch of their own repositories, then pass that link to Geoff’s Learning Management System (LMS), Canvas.

To grade their the project, Geoff downloads the code through the GitHub desktop client, runs it, and assesses the lab.

I have the link right there to GitHub, and I click on it, and I download it, go through all their code, run it, whatever, and just go right on to the next one. So it's super fast to take a look at their code and run it, which is great. It's been really easy. It's worked really well.

Creative assignments

Dr. Mitchell Resnick, creator and educator of Scratch, refers to learning experiences with “low floors, wide walls:” activities that are easy to begin, but enable a creative flow that keeps learners engaged past the requirements.

Geoff’s labs aim to spark this kind of engagement in his students. The Cityscape Lab, one of four over the semester, offers few concrete specifications: create three classes and animate your Cityscape in some way.

So, that's the low floor and for some students, that's going to be a stretch and they're going to work really hard to do that.

But then for others, it's like, "Well, you could do more." We haven't done loops or anything yet so I say, can you figure out how to do windows, other than having to draw all 100 of them by hand? or *can you figure out basic looping structures? 

And I've had submissions like a student who downloaded constellation star data so the stars in the sky actually matched reality. I'm sure she spent hours and hours outside of class working on that but she was really excited about it, whereas other students just got their buildings done, and that's fine.

What I have been surprised about, because I was worried about it at first, is that when students meet the requirements they don't stop.

Top Classroom hacks

Geoff has several AP Computer Science courses a day. When he’s demonstrating to his class and projecting code snippets or examples, he uses one branch per class period.

So when Period Four starts on Tuesday, Geoff picks up from yesterday’s branch:

Every day I update Canvas with a link to the branch of each class period. If a student is absent, they know where to find everything we did together as a class yesterday. And that's been really great.

Take risks, trust each other

Geoff only grades exams and a summative lab at the end four units. All the other projects, daily hands-on activities, and everything else, is all practice.

By putting projects front-and-center instead of grades, Geoff says students are more open to learning experiences that might put them in more vulnerable positions, like sharing work and pair programming.

Students say to themselves, "I can take risks. I'm not being graded on this. I'm not worried about my partner not doing as well as me, because we're just practicing." That trust goes a long way towards helping them accept different kinds of activities.

—
This post is the first in our “Teacher Spotlight” series. We’ll share the different ways instructors use GitHub in their classrooms, and facilitate discussions in the Education Community.

Join this week’s discussion: What are your favorite resources for teaching programming?

CARTO is the newest addition to the GitHub Student Developer Pack.

CARTO is a powerful open platform for discovering and predicting key insights underlying the world's location data. It's a suite of geospatial tools, services, and APIs for discovering and predicting the key insights from your location data in your applications. You'll be able to do powerful analysis of your data.

With CARTO you get:

• CARTO Builder, a web-based drag-and-drop analysis tool for users to discover and predict key insights from location data.
• CARTO Engine, a one-stop shop of geospatial tools, services, and APIs to discover and make predictions with your location data.
• A Mobile SDK that lets you develop custom applications with maps on any mobile platform—Android, iOS, and Windows Mobile 10.
• Location data services that let you obtain maps and services on native applications, using them on the web with open source JavaScript or third-party libraries.
• Data Observatory services so you can turn your data or address locations into comprehensive reports about the characteristics of the local population.

Members of the pack get:

• 350MB Database Storage
• Synced Tables
• $5 worth of LDS credit per month
• 10K tweets per month
• 100K mapviews per month
• Free account upgrades with increased database storage
• Real-time data
• Location data service credits
• Premium features

The Student Developer Pack gives students free access to the best developer tools from different technology companies like Datadog, GitKraken, Travis CI, and Unreal Engine.

Students, get mapping now with your pack.

Starting January 31, 2017, the Recover Accounts Elsewhere feature will let you associate your GitHub account with your Facebook account, giving you a way back into GitHub in certain two-factor authentication lockout scenarios. If you've lost your phone or have otherwise lost the ability to use your phone or token without a usable backup, you can recover your account through Facebook and get back to work. See how the new recovery feature works on the GitHub Engineering Blog.

Currently, if you lose the ability to authenticate with your phone or token, you have to prove account ownership before we can disable two-factor authentication. Proving ownership requires access to a confirmed email address and a valid SSH private key for a given account. This feature will provide an alternative proof of account ownership that can be used along with these other methods.

To set up the new recovery option, save a token on the security settings page on GitHub. Then confirm that you'd like store the token. If you get locked out for any reason, you can contact GitHub Support, log in to Facebook, and start the recovery process.

Pull request reviews are a great way to share the weight of building software, and with review requests you can get the exact feedback you need.

To make it easier to find the pull requests that need your attention, you can now filter by review status from your repository pull request index.

Use the Reviews filtering menu to see the pull requests still awaiting review, unreviewed pull requests on protected branches that require a review, approved pull requests that are ready to merge, and pull requests that have a review requesting changes.

You can also filter pull requests that have been reviewed by a specific user and quickly locate those that have required your review in the past to decide which needs your attention first.

Finally, we've also added review requests to the global pull request dashboard so you can see all pull requests awaiting your feedback across all of your repositories and organizations.

You're welcome to drop any questions, comments, or feedback into our help form.

No need to toggle between windows, you can now manage pull requests without leaving Visual Studio. The GitHub Extension for Visual Studio includes a new pull request window that lets you review code, make changes, and push those changes back to GitHub. This release also provides support for upstream repository contributors to collaborate on a forked branch.

You can install the extension directly from the Visual Studio gallery or download it from visualstudio.github.com.

Last year we introduced the GitHub Extension for Visual Studio as an open source project under the MIT license. We welcome you to log issues and contribute in the extension repository.

GitHub data is available for public analysis using Google BigQuery, and we’d like to help you take it for a spin.

If you'd like to find out more about what data is available and how it's been used so far, watch this conversation between GitHub Data Analyst Alyson La and Google Developer Advocate Felipe Hoffa. You'll learn the story behind the datasets and what types of analysis they make possible. You'll also see how we've visualized data with Tableau and Looker.

There's a lot of data out there, but it's all available through BigQuery in two large data sets. The original, community-led GitHub Archive project launched in 2012 and captures almost 30 million events monthly, including issues, commits, and pushes. Last year, we worked with Google to release The GitHub Public Data Set, separate tables with information on all projects that have open source licenses, including commits, file contents, and file paths.

You can also use the GH torrent project to complement the existing datasets with additional metadata.

We ran a list of queries on the datasets above to create the open source section of our Octoverse report, but anyone can run an analysis. Here are the results of some of the queries run so far.

• "This should never have happened" has appeared in code comments more than a million times (hear this data point for yourself in this Changelog episode)
• Where does open source happen? GitHub top countries shares which countries have the most open source developers per capita
• How reliable is GitHub? Felipe runs a query to find out in GitHub reliability with BigQuery
• There are a lot of feels in open source. Geeksta examines how emotions are expressed in GitHub commit messages
• Are bigger pull requests better? Jessie Frazelle analyzed the top 15 projects on GitHub in terms of pull requests opened vs. pull requests closed

Happy exploring!