The GitHub Blog

Back in April I said we would share the new initiatives we're launching to ensure GitHub is a welcoming and inclusive company. This work is long term and will remain a constant focus for us, but I wanted to share some of the progress we've made so far.

A few weeks ago we identified a number of areas we'd like to improve, and so far we've focused our early efforts on three in particular: the experiences of women at GitHub, improving feedback, and supporting diversity both internally and externally.

Task Force

In April, a group of employees formed a task force to explore the experiences of female employees at GitHub and surface any issues that might not be obvious. The group has been gathering feedback from some of the women at the company, meeting regularly to discuss, and sharing this feedback internally.

The task force has been using a repository to discuss new ideas and individual experiences, which has been helpful in opening up the discussion to the whole company. We know not everyone wants to share their experiences openly and we are working on developing a formal feedback system (more on that later), but we have already received some good ideas and feedback from the people who have participated.

The big themes we've heard so far:

• We all need to get better at respectful and constructive feedback and communication, both verbal and written.
• We need to better educate employees on everyone's role and function, and we need to especially get better about understanding and appreciating people in non-developer roles.
• We need to do more to celebrate and increase diversity within the company, including women.

Some of the things we're doing based on this feedback:

• We’re in the planning stages of designing a diversity and communication training curriculum for GitHub employees with input from Hubbers and external experts. Topics will include diversity training, effective communication, giving and receiving peer feedback, and conflict resolution.
• We have started informal internal workshops focused on developing leadership skills, and we are looking to create more formalized training programs by early next year.
• We have started an internal cross-training program where different teams within GitHub educate other teams on what they do. This is part of our push to help everyone understand how different roles and skills contribute to making GitHub work.

The task force will continue to meet, gather feedback, and discuss ways we can improve, and we're encouraging everyone to participate in these discussions. We will also continue to gather feedback from every employee so we know what we can do better.

Improving Feedback

GitHub has historically operated without any formal feedback system. While we've tried to encourage employees to give each other direct feedback, the lack of clear process and training left Hubbers on their own to understand how and when to have conversations with other people in the company.

We are currently in the process of developing and implementing a formal, documented feedback system for everyone in the company. So far we've begun rolling this out in Engineering, our largest department, and we intend to take it further. Our goal is to ensure that everyone has frequent, constructive feedback and someone they can go to with questions or concerns who can help them. We want people to know where they stand and that someone has their back, and in the past we haven't been good at this.

We've also been expanding our HR team since hiring a head of HR in January and are using their experience to help develop this system, from the communication training program I mentioned earlier to clear steps to take when you need help.

Supporting Diversity

Supporting diversity has always been important to us but recently we've been ramping up our support, participation, and sponsorships for community groups and events that promote diversity in tech. This includes sponsoring more groups focused on helping women in tech and sending employees to conferences focused on these issues, such as the The Grace Hopper Celebration of Women in Computing.

We’re also planning to use the community space at our San Francisco headquarters to sponsor and host more frequent diversity-focused events, including events led by community organizations, official GitHub events, classes, and meetups.

If you’re interested in using our space, are seeking sponsorship, or have an idea for how we can help, please let us know: https://community.github.com

One of the biggest lessons I've learned over the past few weeks is improving isn’t just about developing solutions - a huge part is getting good at surfacing problems. Without a solid feedback system, without talking to people regularly, without explicitly focusing on these issues, without asking people how they're doing and having them feel safe telling you the truth, you'll never know what the real problems are. If people feel like they can't speak up, you'll never hear what they have to say, and you'll never know they're not saying it.

Making GitHub a great place for everyone is something we have to work towards every day. In the future we’ll continue to post about new initiatives, updates on our progress, information on how our philosophies around things like sponsorships are evolving, and details on events we're hosting or participating in. Consider this post the first of many.

The most organized people know that finishing a task rarely involves just one step. That's why we're excited to announce nested task lists!

For example:

- [ ] Figure out wormholes
  - [ ] Call @arfon
  - [ ] Research ([docs](http://en.wikipedia.org/wiki/Wormhole#Time_travel))
  - [ ] Build prototype #15
  - [ ] Test run #43 @world-domination/time-travel
- [ ] ...?
- [ ] Profit!

Now renders as:

Updates work as before: check items on and off to update their completion state.

For more information, see the Writing on GitHub article in the GitHub Help.

GitHub is being used today to build scientific software that's helping find Earth-like planets in other solar systems, analyze DNA, and build open source rockets.

Seeing these projects and all this momentum within academia has pushed us to think about how we can make GitHub a better tool for research. As scientific experiments become more complex and their datasets grow, researchers are spending more of their time writing tools and software to analyze the data they collect. Right now though, these efforts often happen in isolation.

Citable code for academic software

Sharing your work is good, but collaborating while also getting required academic credit is even better. Over the past couple of months we've been working with the Mozilla Science Lab and data archivers, Figshare and Zenodo, to make it possible to get a Digital Object Identifier (DOI) for any GitHub repository archive.

DOIs form the backbone of the academic reference and metrics system. With a DOI for your GitHub repository archive, your code becomes citable. Our newest Guide explains how to create a DOI for your repository.

Academic accounts on GitHub

We also know that as a scientific researcher, sometimes you're going to want to work privately. That's why we've created a discount where individual academic researchers can receive a free micro plan with 5 private repos, while research groups can receive a free silver plan with 20 repos.

To set up an academic account on GitHub, first associate an academic email address with your account and then request a GitHub Education discount.

Awesome science happening on GitHub

If you're interested in seeing all the science happening on GitHub, check out some of our favorite projects, including rOpenSci. This group recently held a Hackathon at GitHub HQ, where their team worked with collaborators from academia, business, and various research labs to build open source tools for science.

Lots of businesses today are experimenting with open source, both by maintaining open source projects and also by internalizing open source workflows. However, adopting open source tools in a business context often presents a steep learning curve. Implementation isn't always straightforward, and cultural changes can sometimes be long-term and tedious.

On Wednesday, May 28, 2014, we've invited a set of speakers to GitHub HQ to talk more about this topic for our first ever public Town Hall, moderated by Eric Knorr, Editor In Chief of InfoWorld. Join us to hear more about how open source is evolving inside companies from:

• Chris Aniszczyk, Twitter
• Kurt Chase, Autodesk
• Dominik Tornow, SAP
• Nate McWherter, GE

Event Details

• When: Wednesday, May 28, 5-9 pm
• Where: GitHub HQ, 88 Colin P Kelly Jr. Street, San Francisco CA
• Space Limited: Please RSVP

Update: If you're not able to attend the Town Hall in person, we will have a live stream available. We'll share the link here and on Twitter next week before the event starts.

Because we love sharing, we use Gist every day to pass snippets of code, writing, notes, and more to each other. One thing we've noticed with all this sharing is that we've all created Public Gists that we meant to make Secret and vice versa.

Starting today, you can change the visibility of your Gists whenever you want. When editing a Gist you'll now notice a new option to toggle the visibility between Public and Secret. The URL for your Gist will never change, just its visibility.

For more information on the differences between Secret and Public Gists, please see this helpful document.

Happy Gisting!

We're excited to share some recent improvements to GitHub Pages, which you may have already noticed rolling out over the past several weeks:

Additional metadata for organization pages

Many large organizations like Adobe, Netflix, and The Consumer Financial Protection Bureau use GitHub Pages to showcase their open source efforts. We've just made it easier to create beautiful pages for you and your projects by exposing additional project and organization metadata to the site.github namespace:

• contributors - A list of your project's contributors, as returned through the contributors API

• public_repositories - A list of your public repositories as returned from the repositories list API

• organization_members - A list of your organization's public members as returned from the organization members API

Each of these new elements expose complete user/repository objects to Jekyll, and can eliminate the need for making client-side API calls when showcasing your open source efforts on GitHub. For more information on displaying metadata within your Jekyll site, see Repository metadata on GitHub Pages.

Sitemaps

We recently open-sourced and white-listed the jekyll-sitemap plugin. By simply adding the plugin to your site's config file, Jekyll will automatically generate a sitemaps.org-compliant sitemap, making it easier for search engines to index your site's content. For more information, see Sitemaps for GitHub Pages.

Better build feedback

You may have already noticed that following some successful builds you may receive a warning email with helpful feedback about CNAME errors, upgrading your Markdown interpreter, or ensuring your custom domain is properly configured.

Additionally, if your page build does fail, we'll provide you with a link to an error-specific help article so that you can get the problem sorted out in no time.

PageBuild events

A few weeks ago we introduced the PageBuild webhook. If you subscribe to the page_build event, we'll ping your application with the result of your site's build following each push. You can use this information to better integrate GitHub Pages with your current development workflow.

Happy documenting!

Ten weeks ago we debuted Atom, the new text editor that's deeply programmable but also easy to use. Starting today, Atom is available for download to everyone–completely free and open source.

Because we spend most of our day in a text editor, the single most important feature we wanted in an editor was extensibility. Atom is built with the same open source technologies used by modern web browsers. At the core of Atom is Chromium, the open source project behind Google Chrome. With that comes all the power and innovation being developed for the web. But more importantly, extending Atom is as simple as writing JavaScript and CSS, two languages used by millions of developers each day.

We are open sourcing all of Atom under the MIT license. You can read more about these components on the Atom blog. Our dedicated team within GitHub will continue to develop Atom, but we welcome the creativity, support, and enthusiasm of the open source community to help us make it even better. After ten weeks in public beta, the community has already published 800 packages that extend its capabilities. We look forward to many more to come.

Atom is currently pre-1.0 with a number of areas we would like to improve in the next few months. Our focus will be on improving performance, releasing Atom on Linux and Windows, and stabilizing the APIs before we hit version 1.0.

Download Atom now, and get hacking on it today by creating a package or forking the Atom repository. To stay up to date on all things Atom, follow @AtomEditor.

We just shipped our latest GitHub Guide: Hello-World. The "Hello World" project is a time-honored tradition in computer programming and now there is one just for GitHub. Hello repositories and Pull Requests! Hello Issues! Hello branches!

The Hello World guide walks you through the core Git and GitHub elements. When you're done you'll have a bright green contribution square and a repository to keep track of ideas or feedback.

GitHub New Users

We love that people are using GitHub to learn development and contribute to open source. We're excited to keep sharing the love with excellent help docs, YouTube Guides, free online classes, and Patchwork nights. Stay tuned, we're working hard on more interesting ways to help you learn and teach GitHub.

We have a team of designers and engineers lead by our most excellent user researcher, @chrissiebrodigan, focused on improving the experience for GitHub's new users. We want everyone to build software better, together -- especially if you're just getting started.

If you have a minute we'd love to know how you learn and teach Git and GitHub. We'll also share what we learn back here with you in a future post too.

Documenting the code you share on GitHub can contribute tremendously to the success of your project. When your documentation is easy to access and read, people can better understand how to work with your code and how to contribute as collaborators.

Today we're shipping several UI improvements that make it easier to create, edit, and interact with GitHub Wikis. These changes also make wiki content more consistent with other repository features and pave the way for future updates.

GitHub Wikis now feature:

• an upgraded sidebar that lists all of the pages in your wiki along with any custom content you'd like to include
• more consistent rendering of wiki content alongside other markup in a repository
• emoji
• task lists

If you haven't yet enabled a wiki for your project, we've published a Guide to help you get started, and have compiled a showcase of projects that have fantastic wikis for inspiration. Need more help? Check out our revamped documentation articles.

A little over 6 years ago we launched github-services as an open source project. We've had a great deal of success with github-services, but the growing number of supported services make it difficult to identify the ones that are important to you.

Today we're introducing a more streamlined way of managing services. With the new changes you'll only see the services that you install, and services are searchable from an auto-completer or by scrolling.

Last Monday I published the least open and least transparent blog post GitHub has ever written.

We failed to admit and own up to our mistakes, and for that I'm sorry. GitHub has a reputation for being transparent and taking responsibility for our actions, but last week we did neither. There's no excuse. We can do a lot better.

I'd like to share with you as much as I can about what happened and a bit about how GitHub is changing.

When the allegations against GitHub were raised publicly we took them seriously and within days launched an investigation into what happened. We hired Rhoma Young, an independent, third-party investigator that GitHub had never worked with before. Rhoma has a long history of conducting fair and impartial investigations, with 30+ years of HR experience. She has worked with every type of organization, from Fortune 50 companies to local governments, and frequently testifies as an expert witness for both plaintiffs and defendants in depositions, arbitrations, and in litigation involving discrimination, harassment, retaliation, disability, and mitigation of damages.

Most importantly, Rhoma does not have a history of siding with companies or otherwise being a partisan, industry spokesperson. Half of her litigation witness work is on the side of employees, half for companies. Her job is to investigate situations and figure out what actually happened, even when the people who hired her don’t want to hear it.

We gave Rhoma free rein to review all the media reports, public allegations, and HR records so she could create her own investigation and interview plan. She identified three key issues that she focused her investigation on: the claims about Tom and his wife, the claims about the male engineer, and the general culture and working environment at GitHub.

Rhoma identified the employees she wanted to talk to based on an initial list we provided, the evidence she gathered, employees who asked to speak with her, people Julie asked her to speak with, and anyone else she determined was relevant, including Julie herself. Ultimately she conducted over 50 interviews during a four week period. Along with the interviews, Rhoma gathered and reviewed evidence consisting of emails, texts, transcripts, and code from the dozens of current and former GitHubbers she spoke with. She then took everything she learned and summarized her findings for GitHub's Board of Directors.

During the investigation, Rhoma promised participants confidentiality and we need to honor that promise. Rhoma’s report includes personal stories, private thoughts, documents, and all kinds of details that were shared for the purpose of the investigation, not for public consumption. We are trying to be transparent, but I hope you understand that there are privacy concerns preventing us from sharing the report in full. That said, I do want to provide more context for the findings we shared in last week’s blog post.

• Founder allegations. The investigation found Tom Preston-Werner in his capacity as GitHub’s CEO acted inappropriately, including confrontational conduct, disregard of workplace complaints, insensitivity to the impact of his spouse's presence in the workplace, and failure to enforce an agreement that his spouse should not work in the office. There were also issues surrounding the solicitation of GitHub employees for non-GitHub business and the inappropriate handling of employee concerns regarding those solicitations.

  After being presented with the results we felt Tom could no longer be an effective leader at GitHub. He offered his resignation and we accepted.

• Engineer allegations. The investigation found no information to support misconduct or opportunistic behavior by the engineer against Julie or any other female employees in the workplace. Furthermore, there was no information found to support Julie’s allegation that the engineer maliciously deleted her code. The commit history, push log, and all issues and pull requests involving Julie and the accused engineer were reviewed. The investigation considered all possible commits surrounding the accusation of passive-aggressive code removal. One instance was found where the engineer updated and broke some CSS in an internal application, which was fixed in a later commit. The investigator determined this change did not appear malicious.

• GitHub’s working environment. Rhoma spent a significant amount of time investigating Julie’s claims of sexual and gender based harassment. After interviewing over 50 employees, former employees, and reviewing evidence, Rhoma found nothing to support a sexist or discriminatory environment at GitHub, and no information to suggest retaliation against Julie for making sex/gender harassment complaints. Employees were asked about their experiences here, good and bad. Women at GitHub reported feeling supported, mentored, and protected at work, and felt they are treated equitably and are provided opportunities.

Even so, we work in a world where inequality exists by default and we have to overcome that. Bullying, intimidation, and harassment, whether illegal or not, are absolutely unacceptable at GitHub and should not be tolerated anywhere. GitHub is committed to building a safe environment for female employees and all women in our community.

Our rapid growth left the leadership team, myself included, woefully unprepared to properly handle these types of situations. We're very aware this is a weakness, now more than ever, and it's naive to think we won't have these issues in the future. But learning how to properly handle conflict and building a safe working environment are two of our most important priorities.

I'm sorry to everyone we let down, including Julie. I realize this post doesn't fix or undo anything that happened. We're doing everything in our power to prevent it from happening again. Recently we hired an experienced head of HR and we clearly documented channels of communication that any GitHubber who needs support can use to make sure problems are dealt with effectively, but know we need to do more. In May we'll be sharing publicly the changes and the new initiatives we're launching. We love GitHub and we want it to be an inclusive and welcoming company worthy of the amazing people in our community and the amazing people that work here.

Thank you to all the GitHub employees, fans, and critics who gave us feedback this week. Your blog posts, tweets, and emails told us we could do better, and you were right.

Task lists in issues, comments, and pull request descriptions are incredibly useful for project coordination and keeping track of important items. Starting today, we are adding read-only task lists to all Markdown documents in repositories and wikis. So now, when you write:

### Solar System Exploration, 1950s – 1960s

- [ ] Mercury
- [x] Venus
- [x] Earth (Orbit/Moon)
- [x] Mars
- [ ] Jupiter
- [ ] Saturn
- [ ] Uranus
- [ ] Neptune
- [ ] Comet Haley

It will render like this, everywhere on GitHub:

Edit the document or wiki page and use the - [ ] and - [x] syntax to update your task list.

Last month, a number of allegations were made against GitHub and some of its employees, including one of its co-founders, Tom Preston-Werner. We took these claims seriously and launched a full, independent, third-party investigation.

The investigation found no evidence to support the claims against Tom and his wife of sexual or gender-based harassment or retaliation, or of a sexist or hostile work environment. However, while there may have been no legal wrongdoing, the investigator did find evidence of mistakes and errors of judgment. In light of these findings, Tom has submitted his resignation, which the company has accepted. Tom has been a huge part of this company from the very beginning and we appreciate all that he has done for GitHub. We wish him the best in his next endeavour.

As to the remaining allegations, the investigation found no evidence of gender-based discrimination, harassment, retaliation, or abuse.

We want to create a great place to work for all our employees and we can’t do that without acknowledging the challenges that exist in providing an inclusive work environment. We are implementing a number of new HR and employee-led initiatives as well as training opportunities to make sure employee concerns and conflicts are taken seriously and dealt with appropriately. We know we still have work to do.

Chris Wanstrath
CEO & Co-Founder

We love using GitHub to write notes on specific lines in a diff — now it's super easy to do from any smartphone!

Just bring up your favorite pull request or commit, tap the line you'd like to write a note on, and start the conversation!

On April 7, 2014 information was released about a new vulnerability (CVE-2014-0160) in OpenSSL, the cryptography library that powers the vast majority of private communication across the Internet. This library is key for maintaining privacy between servers and clients, and confirming that Internet servers are who they say they are.

This vulnerability, known as Heartbleed, would allow an attacker to steal the keys that protect communication, user passwords, even the system memory of a vulnerable server. This represents a major risk to large portions of private traffic on the Internet, including github.com.

Note: GitHub Enterprise servers are not affected by this vulnerability. They run an older OpenSSL version which is not vulnerable to the attack.

As of right now, we have no indication that the attack has been used against github.com. That said, the nature of the attack makes it hard to detect so we're proceeding with a high level of caution.

What is GitHub doing about this?

UPDATE: 2014-04-08 16:00 PST - All browser sessions that were active prior to the vulnerability being addressed have been reset. See below for more info.

We've completed a number of measures already and continue to work the issue.

1. We've patched all our systems using the newer, protected versions of OpenSSL. We started upgrading yesterday after the vulnerability became public and completed the roll out today. We are also working with our providers to make sure they're upgrading their systems to minimize GitHub's exposure.

2. We've recreated and redeployed new SSL keys and reset internal credentials. We have also revoked our older certs just to be safe.

3. We've forcibly reset all browser sessions that were active prior to the vulnerability being addressed on our servers. You may have been logged out and have to log back into GitHub. This was a proactive measure to defend against potential session hijacking attacks that may have taken place while the vulnerability was open.

Prior to this incident, GitHub made a number of enhancement to mitigate attacks like this. We deployed Perfect Forward Secrecy at the end of last year, which makes it impossible to use stolen encryption keys to read old encrypted communication. We are working to find more opportunities like this.

What should you do about Heartbleed right now?

Right now, GitHub has no indication that the vulnerability has been used outside of testing scenarios. However, out of an abundance of caution, you can:

1. Change your GitHub password. Be sure your password is strong; for more information, see What is a strong password?
2. Enable Two-Factor Authentication.
3. Revoke and recreate personal access and application tokens.

Stay tuned

GitHub works hard to keep your code safe. We are continuing to respond to this vulnerability and will post updates as things progress. For more information as it's available, keep an eye on Twitter or the GitHub Blog.