The GitHub Blog

If you’ve got time August 13th - September 13th, challenge your l33t game development skills in js13kGames—a game jam for HTML5 game developers.

Like most game jams, participants make games based on a secret theme announced at the start of the competition. Unlike most game jams , submissions are limited to just 13 kilobytes after minification and compression. That doesn’t sound too challenging until you realize that a JavaScript game engine like Phaser is 815kB minified, and the image below is 13kB...

If you’re thinking this constraint would stifle creativity and limit playability, you’re mistaken. Check out some examples below as js13kGames organizer Andrzej Mazur (@end3r) looks back over some attention-grabbing entries from previous years.

2012

The premier event kicked off and challenged participants to create a game based on the theme Number 13. The winning entry was a mouse accuracy and agility game called SpacePi by @jackrugile that revolves around the defense of 13 bases.

“It was the first js13k entry I started playing and couldn't stop. I spent half of the day sucked to the monitor by the awesome gameplay, beautiful visuals, and overall feel. I sent the link to my friends, and a few hours later they were still complaining they couldn't stop playing!” - @end3r

2013

This year’s theme was Bad Luck, and @jackrugile won for the second year in a row with Radius Raid—a space themed shoot 'em up where you blast away unrelenting enemies before they destroy you.

“The amount of polish and attention to detail is still impressive, even after so many years have passed.” - @end3r

2014

2014’s theme was The Elements: Earth, Water, Air, and Fire.

Competition was tough. Ultimately, @Siorki took first place with Pest Control : Weasels—an arcade puzzle game similar to Lemmings (but with a twist).

“The overall quality of the entries in 2014 went through the roof. I really enjoyed the mayhem and visual effects of Extreme Mini Massacre, and was impressed by AP11, which looked like a proper GTA1 inspired game one could made in 13 kilobytes.” - @end3r

2015

The theme for 2015 was Reversed.

In Behind Asteroids — The Dark Side by @gre, you play a classic game of Asteroids, but don’t control the ship! @remvst placed twice in 2015—in fifth with Taxi Drift and fourth with It's Raining... Boxes?! ”Two games in the top 5 out of 160 entries is really impressive,” according to @end3r.

“I was in love with the style of the main character of Captain Reverso, played RoboFlip, deeply enjoyed Road Blocks, and the winning entry Behind Asteroids showed other devs that you can actually use shaders within the limit and end up with incredible effects like a shadow of the player approaching the machine.” - @end3r

2016

As the name of the top two entries from 2016 (Evil Glitch and Glitch Buster) might suggest, last year’s theme was Glitch. Even after the competition the developers (@agar3s and @remvst respectively) continued work on their entries and published the games on Steam.

“It's great to see the ideas that were born during the compo end up as full-blown games widely available to the public. They’re both available as prizes this year, so they can serve as an example of what can be achieved if you really believe in what you're doing.” - @end3r

2017

The theme for this year will be announced on August 13th. Be sure to check out the js13kGames website for more information, and resources to help get started. You'll find micro game engines and boilerplates, the latest minification tools, audio and video, tutorials, and more!

Inspire your inner adventurer with our fearless Questocat by your side. From merging old pull requests to exploring new lands, you'll always be ready to commit to adventure—just look at the back of your shirt if you need a reminder. This vintage game-inspired design is available now in the GitHub Shop.

Get your Questocat tee

Adventure over to the GitHub Shop to get one before they're gone. And pick up a Piratocat or Social Coding shirt for just $17.50 as part of our Closeout Sale while you're there!

We shot all Questocat photos at Brewcade SF. Check out upcoming Brewcade events.

The biggest barrier to code review is often time, but there's a new way to easily understand how changes impact your code. Now you can navigate to changed methods and functions right from your pull request file finder.

Searching the file finder for a method or function in a Go, JavaScript, Ruby, or TypeScript file will provide you with a timeline-style view of the results, so you can skip to the most impactful parts of a pull request. Check out the documentation to learn more.

We hope this helps make your review process even more efficient. Let us know if you have any feedback—or if there are other search functions you'd find useful using our help form.

Last week, Solutions Engineering Manager Aziz Shamim sat down with Datascope Analytics’ Jess Freaner to talk about how data scientists are uniquely positioned to adopt best practices from both science and software—and how her team is using open source practices to enhance collaboration and results. In case you missed it, here's a recording of the webcast, along with a few of our takeaways.

Highlights

Transparency and openness are essential to Datascope’s success.

Feedback and collaborative knowledge-sharing are hallmarks of successful open source projects. Similarly, transparency and constant communication with clients is key to the success in data science according to Jess. Other practices that cross over from open source include frequent check-ins and reviews, shared documentation, and “reference code” that keeps the Datascope Team and clients on the same page.

Data scientists can benefit directly from open source.

At Datascope, teams contribute regularly to open source projects. They also maintain and develop projects of the own, including Textract, a library that extracts text from difficult documents to work with, such as PDFs, and traces, “a library for dealing with unevenly spaced time series that’s quite handy when efficiently working with sensor data.” Building on the knowledge shared by industry peers, Datascope can move their open projects beyond what could they could have accomplished in a vacuum.

Data scientists can start using open source practices today.

Jess and Aziz also shared four key areas of focus for teams wanting to get started with open source. In short, open source can help teams be more iterative, modular, hypothesis-driven, and human-centered. Integrating these concepts into your data science practice can help your team solve problems in a more holistic, collaborative, and agile way.

Hear more from Jess and Aziz in the recording or browse other GitHub resources.

Open source is all about building communities around shared challenges. Thanks to some subtle (and not so subtle) improvements in the past few months, it's now easier to make your first contribution, launch a new project, or grow your community on GitHub:

Contributor badges

One of the best ways to grow your community is to welcome new contributors. To make it easier to identify when a user is new to your project, maintainers now see a "first-time contributor" badge when reviewing pull requests from users that have not previously contributed to the project.

Once the pull request is merged, you will see a "contributor" badge on the user's comments. In addition to being a badge of pride for contributors, the additional flag can also help maintainers better separate signal from noise in lengthy or heated discussions. This information is also exposed via the GraphQL API as the issue, pull request, or comment's authorAssociation.

Easier open source licensing

You've been able to select an open source license template for a while. Now, when you click the "add a license" button from your community profile, or begin adding a LICENSE file via the web editor, you'll be presented with a new license picker:

The license picker offers a brief overview of the license as well as the full text, and allows you to customize any applicable fields before committing the file or opening a pull request.

Simpler email privacy

Joining a community and making your first contribution can be intimidating. For one, not everyone wants their personal information to be public, often inadvertently the default workflow for many Git online tutorials.

While you've been able to hide your email while performing web-based commits for a number of years, and block pushes that expose your email address more recently, now, when you check the "keep your email address private" option in your email settings, we'll also prevent your email from displaying in places like on your profile, in search results, or via the API so that you can contribute more confidently.

We've also made "keep my email private" the default for new users going forward, and regardless of your email privacy settings, your email address will never be visible to logged out users.

Better blocking

Not every open source interaction is a positive one. If you navigate to a repository and someone you've blocked is a prior contributor, we'll show you a warning so that you can make an informed decision if you'd like to contribute to the project or not:

In addition to repositories you own, blocked users are now no longer able to comment on issues or pull requests you author in repositories owned by organizations or other users.

We hope these improvements will help you make your first contribution, start a new project, or grow your community. If you have any questions, check out the building a strong community documentation or get in touch.

In an effort to increase the adoption of FIDO U2F second factor authentication, we're releasing Soft U2F—a software-based U2F authenticator for macOS.

Soft U2F currently works with Google Chrome and Opera's built-in U2F implementations, as well as with the U2F extensions for Safari and Firefox.

When a site loaded in a U2F-compatible browser attempts to register or authenticate with the software token, you'll see a notification asking you to accept or reject the request. You can experiment on Yubico's U2F demo site:

And as of today, you can download the Soft U2F installer and configure it for use with your GitHub account.

Interested in learning more? Head over to our Engineering Blog and read more about the motivations for the project plus the security considerations of hardware vs. software key storage.

A little over three years ago, we launched our Security Bug Bounty Program, a way to reward security researchers who help make GitHub more secure by reporting vulnerabilities in our platform. Today, we're taking another step to support this type of effort on a much bigger scale. Along with Facebook and the Ford Foundation, we've donated $100,000 to the Internet Bug Bounty (IBB) to make the internet safer by catching more vulnerabilities in internet infrastructure and open source software.

How many vulnerabilities has the IBB found?

The IBB is responsible for awarding over $616,350 for more than 625 valid vulnerabilities in some of the most important software the internet community uses including RubyGems, Ruby, Phabricator, PHP, Python, and OpenSSL—$150,000 was awarded for over 250 vulnerabilities in last year alone. So far, $45,000 of hackers' bounties have been donated to organizations like the Electronic Frontier Foundation, Hackers for Charity, and Freedom of the Press Foundation.

How will the IBB use the donations?

Guidelines, bounties, and policies are decided by a volunteer panel selected from the security community. The panel will use the $300,000 to expand the scope of the IBB in two ways: a new Data Processing Program to "encompass numerous widespread data parsing libraries as these have been an increasing avenue for exploitation" and an expansion of "coverage of technologies that serve as the technical foundation of a free and open Internet, such as OpenSSL."

We're excited to support the IBB's vision and can't wait to see this initiative grow.

Learn more about the Internet Bug Bounty

From product design mocks to user help content, GitHub teams use GitHub to build just about everything—and they're often collaborating across different timezones. As we continue to build products that fit all of your team's use cases, we're sharing insights into what's worked (and what hasn't worked) for our team's unique challenges in a new webcast series.

Each webcast will include approximately 40 minutes of tips from our team and 10 minutes of Q&A. Sign up for the ones you'd like to attend below.

Series schedule

July 25: Communicating with issues

In this session, you'll get the training we give new team members when they join GitHub. We'll cover strategies for clear communication, visual structure in issue comments, and how to facilitate discussion. These strategies are integral to how our team uses InnerSource and may help your team's InnerSource approach.

Watch the recording

August 22: Communicating with remote teams

Hear from two of our seasoned managers as they share how we pattern our work to build tools with 60% of our team members being remote. We'll cover communication patterns, the tools we use, and the cultural elements that contribute to more successful collaboration across timezones.

Sign up

September 26: Managing your teams

Sign up for this webcast to receive pratical tips from GitHub managers on how they create workflows that help employees do their best work. You'll learn how to use more GitHub features for managing your team and how to increase productivity with integrations. Finally, you'll learn how to measure your team's success on GitHub, and maybe get introduced to some new ways to celebrate your success.

Sign up

October 24: Managing your projects

In this session, you'll learn how to manage projects using GitHub features like projects, milestones, labels, and assignees. While these are tools we rely on at GitHub, we realize that some project managers need tools with a few more features, so you'll also get an overview of project management solutions in GitHub Marketplace. You'll leave this webcast ready to take your Github projects to the next level.

Sign up

November 28: Writing documentation for your projects

GitHub isn't just for software. Documentation teams use GitHub to create and publish everything from books to user help content. We'll share how we've adapted the GitHub flow to effectively meet our content creation needs. Whether you're on a team of writers or a solo developer, this webcast will introduce you to creating better documentation with GitHub.

Sign up

You write software so that others can use it, but no software is perfect, and sometimes users have questions or run into trouble. To better direct users to dedicated support channels, you can now describe your project's support resources in a SUPPORT file.

SUPPORT files work just like CONTRIBUTING files. They can live in your repository root, .github/, or docs/ folder, and will be displayed throughout GitHub such as above the new issue form:

Instead of describing how to contribute to the project like CONTRIBUTING files do, SUPPORT files can be used to direct users to dedicated support resources, such as community forums, FAQ documents, or corporate support channels.

For more information, see the SUPPORT file documentation, and of course, you can always contact GitHub Support if you have any questions.

Today I am pleased to share our second annual Diversity Report. While we are working every day internally to make GitHub the most inclusive company it can possibly be, this report represents our commitment to the community to be transparent and accountable for continued progress.

This year, we saw growth across key indices as we welcomed more employees from a wide range of backgrounds into the company. Most specifically, we experienced a 2% growth in each of our Black and Asian communities and doubled our percentage of transgender and genderqueer employees (from 1% to 2%). We are extremely proud of this growth, and it is a result of commitments we made last year—commitments to improving our hiring practices and to our community partners who help keep the pipeline robust. While we are cautiously optimistic about our progress year-over-year, there is still a long way to go toward better representation in our company and in the entire sector.

One interesting data point we examined this year is around retention. As we look at our overall attrition rates, there is no significant difference among gender, race, or ethnicity in terms of who is staying with or leaving the company. This is a metric we will continue to keep an eye on and one that we will use to hold ourselves accountable as we build a more inclusive culture. We encourage other companies to do the same.

There are still places where we have more concentrated work to do. Specifically, we lost a percentage point in women in leadership. In addition, we would have liked to have seen stronger growth of people of color in leadership roles beyond a 2% gain.

Something I am proud to announce as part of our overall efforts is the creation of an Office of Employee Experience and Engagement, which will be led by Merritt Anderson. This office will be responsible for employee advocacy, diversity and inclusion, learning and development, and overall workplace experience. In her leadership position as a VP, Merritt will sit on the executive team and we will work together to improve the full experience of GitHub employees from recruitment through the end of their tenure. We continue to commit ourselves to improving employee experience for all people from all backgrounds. This builds on the good work of the Social Impact Team, a team that has strengthened us as a company over the past two years.

You can toggle through the report below to compare our progress year-over-year. My statement from last year can be found here.

Onward,

Chris Wanstrath

When you first started using GitHub, you read every notification that trickled in with interest and stayed up-to-date on projects with ease.

It gets more difficult when you start to watch an active open source project or work at a company that uses GitHub heavily. Now you find yourself with hundreds or thousands of GitHub notifications every day and struggle to keep up.

Here are a few good practices that can help you manage your notifications so you can focus what's important.

Reduce the amount of notifications you receive

The first step to getting your notifications under control is reducing the number of notifications you receive that you don't care about.

Unwatch repositories

In the past, you watched a repository because you found its activity useful at the time. If you're now ignoring most of its notifications, consider unwatching it. Look through the repositories you're watching on your watched repositories page, and unwatch any of them with a single click.

Leave teams

If you joined teams in a GitHub organization—like an open source project or company—but don't get relevant information from those teams, try leaving them. See all the teams you're a member of in the "Teams" tab on your organization's GitHub page by selecting "My teams" from the "Members" drop-down menu. As an example, the URL for teams in the GitHub organization is https://github.com/orgs/github/teams?query=members%3Ame; replace github with your organization's name to jump straight to your page.

Lock conversations

If the discussion continues on an open source project's issue, pull request, or commit long after it's relevant, you can lock the conversation to avoid anyone receiving future notifications on that issue. To avoid any future notifications for you alone, unsubscribe from the issue or pull request instead.

Prioritize the notifications you receive

Now that you're subscribed to relevant notifications, it's time to check your email. If unsubscribing was enough to clean up your emails, you can stop here. If you still receive find it hard to figure out which notifications to read first, we have more tools to help you.

Notification emails on GitHub provide the notification reason through email headers and a CC email address. This allows you to differentiate between notifications where:

• There was activity on an issue or pull request you created
• Someone mentioned your username
• Someone mentioned a team you're a member of
• Someone mentioned a milestone you're subscribed to
• You received an issue or pull request assignment
• An issue or pull request you're subscribed to was either closed or opened
• Someone committed to a pull request you're subscribed to
• You commented on an issue or pull request
• You opened, commented on, or closed an issue or pull request

Read more about email headers in the notification email documentation.

Automatically triage your inbox

To help triage, try filtering your GitHub email notifications so they're sent directly to relevant folders. This means if you have five minutes to scan your email, you can focus entirely on direct mentions where others are unlikely to respond on your behalf. Your inbox will also be clearer for emails that aren't GitHub notifications.

If you find receiving email notifications more useful, you can also disable web notifications and configure when and why you receive email notifications on your notifications settings page. If you're going to manage all your notifications in your email client, consider enabling "Include your own updates" to be able to see your own contributions to conversations and provide yourself with more context. To avoid extra noise, filter these as read/archived by default in your email client.

Continue work in progress

Your notifications are now organized, but there will still be times you'll want to pick up right where you left off. Use your created pull requests page and created issues page to see your most recent work on GitHub. This will also help you complete your pull requests—always a good idea before opening new ones.

Congratulations! Your notifications are now under control. We hope our tips have helped you work more efficiently on GitHub. Check out our Best Practices for Maintainers open source guide for more ideas from open source maintainers on how to run high-volume GitHub projects. If you have any tips and tricks of your own, we'd love to hear about them.

Manage your repositories' incoming issues more efficiently with a few new updates: a keyword and saved reply to mark duplicate issues, along with a clearer, more informative style for keywords.

Marking an issue as a duplicate

Sometimes your users report the same bug, or your teammates share the same idea. No matter why a redundant issue was posted, you can now mark it as a duplicate of another issue.

To flag a duplicate, add a comment using the duplicate of keyword followed by the issue number or URL. A "Marked as duplicate" timeline event will appear in the timelines of the referenced issues.

Learn more about duplicate issues

Improved keyword styling

We've updated the way keywords are displayed in issues and pull request to give you more information. Keywords like closes are highlighted, and when you hover over them, you'll see a tooltip explaining what the keyword means. For closes, you'll learn that the referenced issue will close when the pull request is merged.

Learn more about using keywords

Nearly three years ago GitHub joined millions of people and hundreds of companies to support the open internet. In 2015 the United States Federal Communications Commission (FCC) passed net neutrality rules under which broadband providers may not block access to legal content, applications, services, or non-harmful devices; impair or degrade lawful internet traffic on basis of content, applications, services, or non-harmful devices; or favor some lawful internet traffic over other lawful traffic in exchange for consideration of any kind.

We won that battle, but broadband providers have been challenging the rules in court (see a brief we joined defending net neutrality) and elsewhere.

Earlier this year, the new FCC commissioner proposed rolling back the rules. Along with 1,000 companies, we asked the commissioner to reconsider and protect the open internet.

Today it's your turn, again. Join millions of internet citizens asking the FCC to defend net neutrality.

Chances are, if you're using GitHub, you're building or learning how to build software. Whether you're contributing to open source, building a mobile app company, or creating a more decentralized Internet, we all need a level playing field.

If you are as passionate as you were in 2015, we'll win the battle in the United States once more.

Join the fight for net neutrality today

GitHub presents Field Day—a one-day unconference for leaders of technical student communities. Students will share how they build communities, learn from each other’s successes and mistakes, and explore how they can collaborate in the future. We'll spend the day focusing on how our summer internships in the San Francisco Bay Area can benefit our respective communities at home.

Field Day is a flexibly structured, student-run event. Attendees drive most of the content, and you'll find students giving lightning talks and leading discussions on their experiences.

If you run a student tech club or if you're actively involved in your school’s tech scene, and also happen to be in the Bay Area this summer, we’d love to welcome you at GitHub HQ on July 29th.

Learn more about GitHub Field Day

Professor Chris Lupo has taught at California Polytechnic State University for eight years and recently revamped his upper-level Architecture course using GitHub Classroom. In this post, he shares his workflow for deeper insight into student work, efficient debugging, and community support.

Open tools lead to a hackable classroom practice

At California Polytechnic State University, the motto is “learn by doing”, so it follows that students learn with real-world tools, rather than with board work and problem sets.

There's evidence of this learning philosophy in the tools teachers choose—particularly in open source projects GitHub Classroom and Raspberry Pi.

In group work, we do a lot with Raspberry Pi and students get into the habit of making sure they push to get it on their other systems, or so their partners can download changes. The flow encourages strong development habits. Push early, push often—that kind of thing.

Chris uses Classroom to distribute starter code and create individual and group assignments.

Diagnose, collaborate, fix: a debugging workflow that doesn’t hurt

Chris uses Classroom, GitHub’s collaboration features, and Raspberry Pi to work with students when they get stuck. Here's a quick overview of his workflow:

Quickly access a student repository. Assignments set up through Classroom automatically add Chris as a collaborator, and the dashboard clearly presents a list of student work.

As soon as students click an “invitation link” from Chris, Classroom creates a new repository for them.
Here’s the output from GitHub Classroom in Chris’s course.

Clone and comment in-context. Students can see where changes need to be made and leaves comments directly in their code.

Test the fix on his own Raspberry Pi.

Push the code back to the student’s repository, with fixes and comments.

This workflow solves the cumbersome task of transferring files. Both instructor and student can work from their own environments, instead of switching between computers.

I can clone their work, connect to the Raspberry Pi that I have access to, and run their code. From there I can work with them directly on their code base to show them what steps to take and how to move beyond their current problem. After we work together, I can push the code back to them when we’re done.

I have access to everybody's code all the time. I've not had that capability prior to using GitHub Classroom.

An active community of teachers helping teachers

When Chris has questions about Git or best practices, he reaches out to the GitHub Education Community for advice from other teachers.

I've also found the community really helpful for support. For example, I learned about a script named orgclone that was really useful for me in repository management.

Even though Git and GitHub take some time to get students up to speed, Chris says students are happy with the experience now that he’s implemented GitHub.

Feedback has been very good. There is a little bit of a learning curve for people who have never used Git before, but they all said it was worth it.

Adapt Professor Lupo’s assignments:

• ARM Thumb Simulator
• Cache and Virtual Memory Optimization
• Towers of Hanoi

Use Raspberry Pi assignments for a university setting:

• Raspberry Pi’s “Getting Started with Git” resource for teachers
• Baking Pi - Operating Systems Development at University of Cambridge
• Tetris Duel project from Imperial College
• List of assignments at the University of Glasgow, School of Engineering

See more GitHub Education posts