jamiehannaford
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.
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.
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.
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.
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.
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.
mozzadrella
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.
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 the Bay Area.
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.
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.
joenash
Join us on December 1, for Major League Hacking’s (MLH) 5th annual Local Hack Day, a global hackathon and celebration of learning, building, and sharing. With more than 200 locations around the world, this is the perfect excuse for you to gather with your local tech community or join a new one.
Hackathons are learning-focused invention marathons where participants dream up fun, interesting projects and work in small teams to bring them to life during the event. Your project could be anything from a website to a mobile app to a robot…and beyond! When you’re not working on your project there are also plenty of other things to do attend educational workshops, make friends, or share what you’re learning.
You don’t need to be an expert to participate in Local Hack Day, either. All experience levels are welcome, regardless of whether you’re a first-timer who is learning to code or you attend hackathons regularly. All you need to do is find a location near you from the Local Hack Day website and register.
Everyone who attends a Local Hack Day gets access to the GitHub Education Pack, which has tons of free developer tools to help you build an awesome project (along with lots of GitHub swag). Some of the locations will even have a GitHub Campus Expert available to help mentor participants.
This is MLH’s 5th year organizing Local Hack Day, and GitHub is proud to be hosting the event for the 3rd year in a row. In 2017, the event brought out more than 6,000 participants across 34 countries and 236 cities around the world. This year’s event is shaping up to be the biggest one yet.
Spread the word about Local Hack Day by using the hashtag #LocalHackDay on Twitter, Facebook, or Instagram. We can’t wait to see you there, happy hacking!
joenash
As a student trying to ship code without a community to help you, small setbacks can add up to a massive feeling of frustration, even isolation. Who can you brainstorm with? What about sharing the brilliant solution you devised, 10 pull requests later? As rewarding as contributing to open source can be, it’s also a challenge to go it alone.
GitHub Field Day, a day-long “unconference”, solves this problem by bringing together students from their local communities to connect and share experiences. This summer marked the first anniversary of GitHub Field Day, which has grown to meet the needs of communities around the world.
Intern (and now GitHubber) Wilhelm Klopp (Wil) created Field Day to share information across campuses and learn from mistakes, all while making friends. With an unconference, participants in each session can freely engage in discussions, collaborate, take a break, or decide to move to other sessions.
When you attend a local Field Day, the structure of the event invites you to participate as little (or as much!) as you’d like. Think of it like a “choose your own adventure” game—you control your experience, and you can suggest topics for technical discussions and activities that are timely and relevant to you. More importantly, you’ll have fun, feel welcome, and enjoy meeting other student leaders.
Student leaders talk about Field Day
Every Field Day is different, and each one has something for us to take away to our local communities. Here’s a walkthrough to give you a sense of Field Days from each region, along with some helpful tips.
As a Campus Expert Wil noticed a trend that every Expert reported: when a student leader experienced a problem, who did they turn to? There wasn’t an outlet for them in their local communities. This was how the idea for Field Day started, and Wil set out to launch a beta event.
Inaugural Field Day
One of the key skills you learn as a Campus Expert is how to observe the needs of your community. The first Field Day showed that Wil was onto something—students want this kind of knowledge base, some form of face-to-face support for their shared struggle.
At the time, Field Day’s project name was “Umbrella”—an umbrella event for leaders of technical student communities. Ultimately the name evolved, but the project name still hangs on as part of the branding: the purple umbrella ☔.
The first Field Day unconference schedule included a Pizza programming contest, teaching CS to complete beginners, creating the membership identity, inclusivity of international students, and building an API for students at university
Los Angeles Field Day attendees
Campus Expert Catherine Chung at the University of Southern California has a habit of noticing “what’s missing” in her on-campus community. After joining the ACM chapter, and creating an all-female hackathon for schools in her region, AthenaHacks, she saw how schools in Los Angeles could band together, share resources and distribute the work in ways that would help everyone.
In the spirit of coming together for mutual benefit, Catherine connected USC with UCLA to house Field Day Los Angeles in a larger venue. Working side-by-side to plan the event, both schools shaped it to serve their communities.
For next time, Catherine plans to seed the event with content that students want.
Something that could help add more value to the event is polling the attendees (maybe during the application form) to see what topics or issues they’d like to talk about, or pairing people up into more relevant groups for lunch. For example, it would have been interesting to pair up the ACM (Association for Computing Machinery) student leaders from all the schools in one lunch table so they could talk about collaboration or discuss things they’re working on.
With 33 attendees, Field Day Montreal (organized by Campus Expert and former Intern kim-codes) was small enough to focus on one track for the entire day.
Student leaders opened up about their common problems: recruiting new members, the onboarding process for their organization, keeping in touch with members, and learning how to work as a team. With this agenda in mind, the discussion bloomed to offer solutions (including a poutine day for recruitment).
One interesting challenge Field Day Montreal posed was around language: how do you run a conference for student leaders in multiple languages? Perhaps offer slides in English and French, or ask for translation services from student leaders who are multilingual.
Speakers at Field Day in Mexico
Two of the seven Campus Experts in Mexico, Juan Pablo Flores and Fernanda Ochoa Ramirez, organized Field Day Mexico City in February 2018 for both newcomers and seasoned coders.
For Fernanda, organizing Field Day “changed my life”—she saw ways to improve efficiency, use new communication channels, and bring together 35-50 different communities who previously operated independently. The different clubs shared how to work with universities, sponsors, and the media.
They are currently discussing where to host the next Field Day, and Juan would like to nurture communities outside of Mexico City to grow the ecosystem.
Campus Expert Teresa Luz Miller held Field Day NYC at the offices of Major League Hacking (dubbed “MLHQ”) in Manhattan.
The NYC Field Day started with a kickoff icebreaker activity called “A Cold Wind Blows”, which is a sort of musical chairs game to help people get to know each other. The organizer structured the unconference by asking every attendee to make three post-it notes of what they needed help with—an idea she learned from Maintainerati, the unconference for open source maintainers—and then clustered related ideas together into a schedule. Each small breakout group appointed a facilitator to capture the conversation on the whiteboard, which aided in comprehension and collaboration.
GitHub Field Day has connected students from as far as London and the Midlands in the UK to Mexico City. We would love for you to join us at the next Field Day near you!
Are you a technical student leader in your community? Find a GitHub Field Day or contact your local Campus Expert.
merrittqa
When it comes to building a great company and an incredible product, we know that diversity matters. As I’ve said in the past, “Diversity of experience, background, and identity not only makes us better colleagues, but amplifies our spirit of innovation and our commitment to building the world’s best software platform.”
But not everyone has a clear path to a job in tech. It can be particularly difficult for individuals with non-traditional work and educational backgrounds to find full-time roles. For every computer science graduate we hire, we know there are others who could also make a significant impact at GitHub: people whose work experience is primarily outside of tech and are looking to pivot into the industry; people who have taken time off for caregiving and are coming back into the workforce; and people who don’t have a traditional developer or engineering background (perhaps they are self-taught or participated in a coding program).
With this in mind, we’re proud to launch our new apprenticeship program, lovingly dubbed the ‘Octoprenticeship.’ We’re lowering the barrier to entry into tech to empower people with diverse backgrounds—people who should have a hand in building the future.
An Octoprenticeship is a six-month, paid career development program designed to support individuals with non-traditional work and educational backgrounds. While we already have a successful internship program for full-time college students, we wanted to create a program for folks who don’t qualify for traditional internships. The program provides real-world experience to talented individuals who are passionate about tech and are looking to enter the industry.
Octoprentices (apprentices) gain valuable exposure to the industry, and they get to build their professional network—all while being provided with paid, on-the-job training. But they aren’t the only ones who benefit from the program. Diversity fosters innovation, especially when there’s a greater variety of viewpoints. Many of the apprentices will bring fresh ideas and new perspectives, infusing them into our teams. Ultimately, this leaves a positive impact on how (and what) we ship at GitHub.
Apprentices are given the opportunity to:
We designed our Octoprenticeships to provide the most value possible for the apprentice—and the most value for GitHub as a company. To accomplish this, we made several choices that set our program apart:
We expanded our understanding of “diversity” to include groups who are frequently overlooked in traditional diversity and inclusion programs: caregivers returning to the workforce, individuals pivoting into the tech industry, and developers/engineers without four-year degrees. We also opened the applications to individuals living outside the Bay Area; since GitHub has a highly distributed workforce, Octoprentices can work from our headquarters in San Francisco or work remotely.
We opened up both technical and non-technical roles to reach a wider audience and to help create a path into tech for individuals working in sales or account management (in addition to engineering).
For the duration of the program, apprentices are embedded within GitHub teams and work alongside full-time GitHub employees. This allows apprentices to learn from other Hubbers, contribute to real-world projects, and understand what it’s really like to work in tech.
We want Octoprentices to feel like they’re a part of GitHub and that they truly belong here. To foster a sense of belonging, Octoprentices will begin the program with an in-person orientation and onboarding experience at GitHub HQ in San Francisco. Then they’ll continue to receive support from the Employee Experience and Engagement (EEE) team over the next six months. They’ll also take part in custom learning and development workshops, attend monthly Lunch ‘N Learns with other teams within GitHub, and engage with our many communities of belonging, including Employee Resource Groups (ERGs) and affinity groups.
To make all this possible, we partnered with organizations that align with our values and our mission. We wanted to ensure that we were creating a meaningful experience for everyone taking part in the program—our apprentices, our partners and our broader GitHub teams and community. Our partnerships with Path Forward, Sabio, and TechHire enabled us to not only build an inaugural program we believe in but also hire an exceptional cohort of apprentices.
We’re committed to supporting the personal and professional growth of each apprentice, with a goal of converting all of our apprentices to full-time roles. To evaluate the success of the program, we will check in regularly with apprentices, mentors, and managers. We will use their feedback to improve the experience of the initial cohort and to iterate upon future Octoprenticeship programs at GitHub.
We were overwhelmed and impressed by the hundreds of applicants for our inaugural cohort. Clearly, there is a tremendous amount of talent that is ready and excited to jump in to these roles. We’re kicking off the program tomorrow and couldn’t be more proud of the five apprentices we’ve hired.
