Developers and teams expect business-critical services to be reliable. From our perspective, reliability can be defined by three questions: is the product available, how well does the product recover from failure, and how performant is the product as it evolves over time. In order for millions of developers to develop, build, and deploy their software, the underlying platform that powers GitHub must be resilient to a wide range of failure modes. We understand that our products need to satisfy the levels of trust our community expects of us when putting their code and their livelihoods on our platform. Today, we are pleased to announce the new GitHub Status Page.

Behind the Scenes

GitHub is built on a platform of distributed services, spread over multiple data centers across the globe. An incident can occur on any of one these platform tiers, affecting either a standalone service or a cluster of interrelated components. With that in mind, we needed a way to accurately communicate this level of granularity to our users and designed a new status page to provide this functionality.

Our new status site now lists the individual component statuses that make up our wider product. Now GitHub can communicate the statuses of components that matter most to our users, and users can subscribe to them. Git operations, for example, are now split out from API requests, and Pages builds can be tracked independently of Notifications. This makes our messaging during an incident more accurate and reliable.

In addition to splitting out the component products on the status site, we’ve also focused on improving and organizing the information we provide to users during an incident. Our goal has been to change our workflow to improve our customer communication during an incident and to reduce friction for incident commanders.

To do this, we started by decoupling the idea of a component status update (e.g. Pages is experiencing degraded performance) from the lifecycle of an incident. The degraded performance of a component could be representative of a wider incident, but updating its status does not allow us to track and share mitigation steps and descriptive updates. In other words, status updates are snapshots in time of a specific component, and incidents are trackable communications between GitHub and customers.

Integrating the new status into your operations

One of the benefits of the new status site is the ability to subscribe to our status changes in multiple ways, such as email, SMS, or webhook delivery. These subscriptions can follow the entire lifecycle of an incident from investigation to remediation. For example, if you’re using Jenkins to run a Continuous Delivery pipeline and our Git operations experience a service slowdown, you could create a webhook to have your Jenkins system apply a backoff mechanism to prevent downstream errors.

Deprecating the old status site

Over the next three months, we’ll continue to support our old status site, as well as its API. So you’ll have time to move any integrations over to the new site. Throughout February leading up to the deprecation, we will perform brownouts in an effort to help you identify systems that may be pointing at the deprecated site. At the end of February, we’ll be adding a redirect for web traffic to the new status page and fully shutting down the old API.

Testing out the new site

In addition to deprecating the old site, we will test the new one on our live systems. On December 18, 2018, we’ll be running a test of our new incident response workflow at 10:00 PST (18:00 UTC). Throughout this test, we will have an active incident that starts with "TEST". This test will not reflect the real status of our products, but will only serve as a way to test new tooling, processes, and the status site. Our component products will not be going through any disaster recovery processes. You will notice during that time that services may appear to be degraded via the status site but that won’t be the case. If you do find any issues or problems with the status site during this time, please reach out to us.

Reliability as a product feature

The new status site is the first of many public commitments we’ve made at GitHub to treat reliability and performance as a product feature. Doing so is a responsibility, not only of the engineers, but of our entire organization. This means that product managers and designers care about and prioritize reliability along with and against new features. Over the coming months, we’ll continue to build on this theme, so you can keep putting your trust and your software development workflows on GitHub.

Have feedback? Let us know what you think of the new status page.

Whether you have 100 developers or 100,000, onboarding new team members and sharing knowledge across the organization can be a challenge. At this year’s Universe, we announced GitHub Learning Lab for organizations to help solve this problem at a broader scale for our cloud customers.

We want to make it easier for developers to build their skills, without ever leaving GitHub. And now, with Learning Lab, teams of developers can onboard, train, and share knowledge across their organization, customized to their specific workflows. Since its launch, we’re happy to report that tens of thousands of developers have completed free, hands-on projects to build skills at their own pace.

We’ve been working with you to understand how we can help your teams onboard, train, and innovate faster. Many of you stated that you’d love to bring Learning Lab to your teams, but you need the learning to happen behind your firewall. As of today, Learning Lab for organizations is now available for our GitHub Enterprise customers, too.

We’re excited to see what Learning Lab can do to transform the way your developers learn and share knowledge at scale.

Get your team started on GitHub Learning Lab

All of us share a lot of links on GitHub. In fact, nearly one-third of comments on issues and pull requests include a link. Hidden behind each of those links is important context that can inform the conversation. But each link that navigates you away from the conversation represents a context switch that reduces your focus and the timesaving benefits of productivity tools.

With the Content Attachments API (now in beta) and the growing ecosystem of GitHub Apps, content behind each URL can be embedded directly in the conversation you’re having on GitHub. Apps using the Content Attachments API help developers and their teams stay focused on what matters most: shipping beautiful code—all within GitHub.

New apps using the Content Attachments API

We’re excited to introduce you to four new GitHub Apps that use the Content Attachments API to help you communicate visually, file bugs, plan your projects, and document your system.

RunKit

RunKit solves the “it works on my computer” problem by making it easy for you to file reproducible and runnable bug reports for Node.js projects. RunKit notebooks package a full environment within a container and can be shared with a URL to give project maintainers access. With RunKit and the Content Attachments API, a RunKit link in an issue or pull request now shows the contents of the entire notebook and its output.

Install RunKit Notebook

LeanBoard

Sometimes your team just needs to stand in front of a whiteboard to work through the details of an idea. LeanBoard brings this collaborative experience to remote teams across a shared board of sticky notes. Now, with Leanboard and the Content Attachments API, you can drop a link in an issue or pull request to preserve the conversation. Even better, screenshots in content attachments are updated automatically (every five minutes) as the board changes.

Install LeanBoard

CloudApp

Sometimes visual communication is the most efficient way to quickly and clearly communicate an idea or concept. CloudApp brings the human connection back to digital workflows through video messaging, screen recording, screenshot annotation, and GIF creation. With CloudApp and the Content Attachments API, you can paste a URL to render a GIF or screenshot in your issue and ensure that your teams have clear visual context to resolve issues faster.

Install CloudApp

Lucidchart

Use Lucidchart individually, or as part of a team to create and share architecture diagrams, mockups, user flows, and other visuals. These help communicate an idea visually, and clarify how applications and systems should function. With Lucidchart and the Content Attachments API, you can now add these visuals to a GitHub issue and, unlike static diagrams, they update as your system evolves.

Install Lucidchart

Showcase your content on GitHub

The Content Attachments API brings the work behind your code to the forefront on GitHub. We can’t wait to see how you use it to bring more context to your conversations about software development.

Check out the partner apps and tell us what you think. Ready to make your own app? Head over to the Developer Blog to start building with the Content Attachments API.

This article is part of a series based on our 2018 State of the Octoverse report—trends and insights into GitHub activity, the open source community, and more from the GitHub Data Science Team.

On GitHub, developers can express themselves in their preferred medium: words, code, or tiny cartoon images if they choose. To get a sense of how our community expresses themselves with emoji, we looked at which ones they use in (and in reaction to) issue and pull request comments. Our data on emoji reactions covers public and open source repositories between October 1, 2017 and September 30, 2018.

To learn more about our numbers and methodologies, check out this year’s Octoverse report.

Reactions

In 2016, we released emoji reactions to quiet the noise of contentless issue and pull request comments like +1. So how are you using reactions today?

Total reactions by emoji

Expressions of approval and celebration make up the most of your reactions. In fact, you’re giving the 👍 and celebrating with a 🎉 more than anything else.

Percent of reactions by emoji type and programming language

Looking at projects tagged with a primary programming language, we can see which emoji language communities use most. Comments in Ruby projects had the most ❤️s, and C# users are casting nearly double the 👎s as any other group.

Geographic trends in reactions by continent

Beyond programming communities, geographic trends demonstrate how far some emoji reach. No matter their location, developers react to build consensus and to say, “job well done”. For all of our differences, 👍 is the most widely used reaction across continents. Similarly, more negative emoji like 😕 and 👎 are used less often, suggesting that sometimes, harder conversations require more words.

Zooming in, Japan spread positivity by reacting with more 👍s and ❤️s per user than any other country. And developers in the Czech Republic have something to celebrate. They reacted with the most 🎉s on average.

Reaction-provoking projects

You’ve reacted to public comments on topics from managing code to managing depression, expressing laughter, thanks, and support. In the last year, you:

• Congratulated the creator of Vuetify on career and project milestones
• Extended almost 2,000 👍s to the React team’s plan to modernize React DOM
• Shared a 🎉 in issues opened just to say “amazing job” to CSS paintings (and found abstract art in IE7)
• Gave thanks for time saved by a new library
• And shared feedback in Refined GitHub on Project Paper Cuts (thank you!)

Emoji in comments

Five emoji could never fully represent the complexity of human emotion. When a 👍 isn’t enthusiastic enough, you often post a 🚀. In the last 12 months, the GitHub community created almost 10,000+ issue comments containing no other content but this tiny craft. That’s a lot of warp-speed shipping.

Emoji used in open source issue comments is often tactical, supporting code reviews and to-dos like looking over code 👀, OK-ing changes 👌, fixing bugs 🔨, and applauding good work 👏.

Together, you’re using emoji to transcend borders, get work done, and express playfulness, agreement, and a whole lot of ❤️. We can’t wait to see what new trends in tiny images are up next.

Stay tuned for more posts that dive in data on the GitHub Blog—or check out our reports on projects and programming languages to see what a community of 31 million developers can accomplish in a year.

Connecting the classroom with industry mentors and a high-quality open source curriculum

In 2015, San Francisco Unified School District (SFUSD) became one of the first in the US to include computer science requirements across their entire curriculum. It’s a big shift with wide-reaching implications: some teachers need retraining in computer science, and students want help from experts when they get stuck. That’s where Code Nation comes in, a non-profit dedicated to career readiness in the Bay Area and New York City.

Industry mentors and public schools collaborate

Code Nation, formerly ScriptEd, closes the skills gap by matching high school classrooms with volunteer teachers from industry. Over three years, students experience high-quality curriculum and a paid internship, all while they develop projects on GitHub that connect to their personal passions.

The volunteer teachers—some who teach as much as twice a week—are all professional software developers who want to give back. The 300+ volunteers between New York and the Bay Area plan events, and help students prepare for interviews, making a significant difference in their students’ lives.

In the 2018-2019 school year, Code Nation will reach 1,374 students across 46 high schools in New York City and San Francisco.

A curriculum built and improved through GitHub

At the center of Code Nation’s curriculum are web technologies that students can use as soon as they leave the classroom. At first, students learn that the web is something they can change and build themselves through tinkering with sites like the New York Times.

GitHub is a core part of their curriculum in the second year when students start working with repositories that contain starter code.

Code Nation also uses GitHub to produce their curriculum, and they revise it every year. A group of 20-30 core contributors work together to improve and refine the teaching materials, including volunteers from Google and from the Flatiron School.

“By providing students with a high degree of structured content and the support of volunteers, we can provide them access to building meaningful things,” says Peter Jablonski, one of the staff members at the non-profit organization.

Enabling real impact

The results speak for themselves: since Code Nation started helping schools six years ago, 74 percent of their alumni are currently working in a STEM field, and 63 percent are in computer science. That’s a demonstrable impact, and we’re honored Code Nation uses GitHub to do it.

If you’re training the next generation of developers, offering computer science for the first time, or expanding your department, we can help. Our mission is to equip students with the best tools, events, and training to shape the next generation of software development.

The GitHub Education program offers real-world tools to schools at no charge, meaning high schools can use the same premium tools and workflows as our enterprise customers.

Get GitHub Education for your school