Meet Sean Marcia, founder of Ruby for Good

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

Sean Marcia

If you know Sean Marcia, chances are that it’s through Ruby for Good, an annual event that brings Ruby developers together to work on projects that benefit their communities. But when he’s not empowering developers to use their skills for collective good, he’s partnering with academics at George Mason University to advance their research through software and the web. Oh, and saving the world’s pollinators, of course. We asked Sean to share the story of how he became a developer, and what he’s learned from his work.

Erin: How long have you been developing software?

Sean: Let’s see... It’s been my legit full-time career for about five years now. Like many nerdy types, I’ve been poking and prodding at computers since I was a wee one. Getting paid to do it is a relatively new and delightful thing!

Erin: What programming languages do you use?

Sean: I primarily use Ruby on Rails and Javascript for the projects I work on at George Mason University. I also sneak in Go whenever I am able.

Erin: Who did you look up to in your early days?

Sean: In my early days, full-stop, I definitely looked up to (and continue to look up to) Jim Henson and Mr. Rogers. These guys genuinely cared about people and their happiness. My favourite Jim Henson quote nicely sums up why I admire him so much and what I strive for everyday:

My hope still is to leave the world a bit better than when I got here.

In my early days of career software development, who did I look up to? Hmm, it’s tough to narrow it down to a short few. I definitely have to mention _Why, James Edward Gray II, Greg Brown, Jim Gay, and Evan Light. These folks were helpful (understatement), encouraging, smart, generous with their time and expertise, and just all-around great people; I hope I can offer back even half of what they’ve given me. Ruby fosters a culture of inclusion, kindness, and learning. It’s a community comprised of some of the best people I’ve ever met. As a newbie, I was privileged to be exposed to this great bunch, and now as a Ruby Meetup organizer I count myself lucky to see newcomers’ passion about development and their world.

Erin: Tell us about your journey into the world of software development.

Sean: Okay, brace yourself, best sit down for this one: I've always been a bit of a computer nerd with an affinity towards technology. No big shocker that this interest manifested itself in computer games. The first substantive programming I did was using a language called LPC for a multi-user-dungeon (MUD). That’s right, I wear my nerd badge proudly! For those who have no idea what I’m talking about, MUDs were the precursor to MMORPGs. Everything was text based, there were no snazzy graphics, and they only had a few hundred people playing at once (none of this thousands upon thousands business). It was great fun, as I was friends with a lot of the people who used the things I built and was able to directly observe their happiness and pains when they were interacting. Quite the dichotomy from today when some of the things I build disappear into the ether after delivery and I never see how it is used or what happens next.

Erin: What resources did you have available when you first got into software development?

Sean: Not a lot! I remember begging my parents to buy me Borland's C++ compiler but it was outside their budget so I was only able to read the code in the book but not compile and execute it myself.

Erin: What advice you would give someone just getting into software development?

Sean: I would tell them to get involved in the community! I have learned and benefitted so much from having access to people at meetups, conferences, and other events. I wouldn't be where I am today without the help. I would also let everyone know that you don’t need a computer science degree to get into software development. We live in an amazing world where information is so widely available that you can learn anything you want with a few clicks. It is fantastic that schools like MIT, Stanford, and others have open sourced so many courses. If you have access to an Internet connection you can access courses taught by some of the smartest people in the world. This isn’t to say that software development isn’t hard! Don’t get discouraged. Don’t give up.

Erin: What additional advice would you give someone looking to get into open source?

Sean: I would tell them to not be afraid! Everyone I've met who works on or maintains an open source project is super nice and generally pretty overworked. They are friendly, welcoming to new people, and love the help! An easy way to get started with an open source project is to help with documentation. I think most people would be surprised with how much help even well-established projects need in that area. If you are new to development and are using and learning an open-source project, document your learning, and submit it to the project’s GitHub wiki as a newbie's guide to help others.

Erin: I was inspired (and entertained!) by your talk on saving the bees with Ruby and was amazed at how much you did with so little. What advice would you give to someone with a big, impactful idea, but a small budget?

Sean: Not to sound like a broken record, but get involved with your community! I couldn't have done everything I did without the help of my community. For the project you mentioned, several people donated a Raspberry Pi that would have otherwise been collecting dust on a shelf. Plus, a friend did all the soldering for me and was nice enough to allow me to record him so others could replicate it. And, the wealth of knowledge and feedback that so many people provided made it a success. A lot of people are happy and want to help, you just need to ask!

Erin: Are there any misconceptions out there about software developers that you think need to be retired?

Sean: I think the biggest misconception is that you need a computer science degree to be a software developer. This is an archaic notion as there are so many paths into the software development field, from boot camps to those who are self-taught. One of the best developers I know, who has published several popular books on software development, has a fine arts degree in ceramics. I firmly believe that excellent mentorship, bootcamps, and community events are producing better software developers than universities.

Erin: What role did MINASWAN play in inspiring you to start Ruby for Good? Can you share with us an example or two of how you’ve personally experienced MINASWAN (or perhaps seen others experience it)?

Sean: MINASWAN played a huge part. Outside of the technology industry many people are struggling and I believe that because we have it so good in tech it is easy to lose sight of that. The genesis of Ruby for Good was to provide a way to help and make a difference for the people who need it most. There are everyday MINASWAN heroes in this community and one person I'd particularly like to shine some light on is Zander Hill and the amazing work he does mentoring. Getting into software development can be intimidating and overwhelming, but I've seen Zander take the most difficult concepts and make sense of them for his mentees.

Erin: Okay, we’ve talked a little bit about Ruby for Good, a conference that gets Ruby developers together to hack on projects that make an impact on the world outside of tech. What are some of your favorite projects that have been helped by the conference attendees?

Sean: I think my favorite project was a ticket-tracking app we built. Before we helped them through Ruby for Good, the nonprofit was using a telephone line and its voicemail as their project management tool. The telephone line would ring continuously throughout the day. People would check messages with the rule that you could only delete a message once the task was completed. This required people to forward through as many as 80 messages before getting to the one they needed and they estimated that each employee who used it wasted at least five to six hours a week on the phone. The new system has made their lives much better and given them more time to devote to the great work they are doing. I'm also pretty excited about the help we provided the Fairfax Humane Society because it doesn't get much better than helping puppies and kittens! This year, Ruby for Good is going to be held June 16-19 where we will be helping some truly amazing organizations, including researchers who are working with red pandas. I'd encourage anyone who wants to do good and hang out with red pandas to attend!

Erin: Where would you point someone who wants to get involved, but can’t attend the conference?

Sean: If someone wants to specifically get involved with Ruby for Good, check out the projects with open issues on our GitHub organization page and submit a pull request! I would also encourage people to look closer to home. Stop by a local non-profit that appeals to them and offer to help. One ubiquitous issue among non-profits that we've spoken to is how starved they are for help with technology. Nonprofits desperately need the help that we can offer, but for most part it is completely outside of their budget. Through our volunteer work, they can get new ways of doing things that they might have done the same way for the past 20 or 30 years.

Erin: Anything else you’d like to share?

Sean: I've had a great deal of fun whenever I've been able to use Go and would love to do something more substantial with it. I'd love it if anyone could make some suggestions :).

Git 2.8 has been released

The open source Git project has just released Git 2.8.0, featuring a variety of features, bugfixes, and other improvements from over 70 contributors. Here are some of the most useful new features:

Parallel fetches of submodules

Using "git submodules", one Git repository can include other Git repositories as subdirectories1. This can be a useful way to include libraries or other external dependencies into your main project. The top-level repository specifies which submodules it wants to include, and which version of each submodule.

When you fetch into the top-level repository, you typically want to fetch into the submodule repositories as well:

git fetch --recurse-submodules

If you have a lot of submodules, all of these fetches can be time-consuming; git fetch is essentially run in each submodule in turn. But now you can speed things up by fetching from multiple submodules in parallel. For example,

git fetch --recurse-submodules --jobs=4

runs four submodule fetches at the same time. This should be a real time saver! [source]

Don't guess my identity!

If you use the same name and email address to commit to all of your Git projects, then you can configure those values once and for all in your global .gitconfig file:

git config --global 'Me Myself'
git config --global

But if, say, you want Git to use one email address for your open source projects and a different one for your work projects, you've undoubtedly made the mistake of committing to a new Git repository without having first set your email address in that repository. In this situation, Git emits a warning, but it creates the commit anyway, using an email address that it guesses from the local system hostname. If you're trying to do something as complicated as different addresses for different projects, this is almost certainly not what you want.

Now you can tell Git not to guess, but rather to insist that you set and explicitly before it will let you commit:

git config --global user.useconfigonly true


Convergence with Git for Windows

There has recently been a big push to make Git feel as comfortable on Windows as it does on Linux and OS X. For example, it is relatively expensive to start processes on Windows, so many Git commands that were originally written as scripts have been rewritten in C to make them snappier.

In this release, a bunch of Windows-specific changes have been brought back from the Git for Windows project into the main Git project. This continuing effort will make it easier to keep the functionality of Git in sync across platforms as new features are added. [source, source, source, source]

Along the same lines, several Git commands that use text files as input have been made to accept both LF and CRLF line endings. That should reduce friction on Windows, where many tools may produce files with CRLF line endings. [source]

Security fixes

Git 2.8.0 includes the security fixes for CVE-2016-2324 that were first made available in Git 2.7.4. This vulnerability is not known to have any exploits in the wild, but could result in executing arbitrary code when cloning a malicious repository. We recommend that everybody upgrade to a version of Git with these fixes, namely 2.4.11+, 2.5.5+, 2.6.6+, 2.7.4+, or of course 2.8.0+.

In addition to these fixes, this release contains a number of cleanups designed to make it easier to avoid similar bugs in the future.


Brief mentions

  • Git's clean and smudge filters can now be turned off by setting them to the empty string. This feature is notable mainly because it is used by the new git lfs clone command, which can dramatically reduce the time to clone a repository that uses Git LFS. [source]

  • Git configuration values are read from several different places, including system-level, user-level, and repository-specific files. This can make it hard to figure out where a setting has to be changed. Now you can use git config --show-origin to show where a particular setting came from:

    $ git config --show-origin
    file:/home/me/.gitconfig    Me Myself


  • You can use the new git ls-files --eol FILENAME to help diagnose end-of-line problems in a file:

    $ git ls-files --eol screenshot.png
    i/lf    w/lf    attr/         
    i/-text w/-text attr/                   screenshot.png

    The output shows (i) the EOL style auto-detected from the file's contents in the index, (w) the EOL style detected from file's contents in the working copy, and (attr) the style that is configured for the file via gitattributes. [source]

  • git ls-remote can now also tell you a remote repository's default branch:

    $ git ls-remote --symref origin HEAD
    ref: refs/heads/master  HEAD
    db6696f653b917509dac1ac13b922e12773a84ff        HEAD


  • Support for cloning via the rsync protocol, which was superseded long ago by better alternatives, has been dropped. [source]

The rest of the iceberg

That's just a sampling of the changes in Git 2.8.0. Check out the the full release notes for the complete list.

[1] Git submodules are analogous to Subversion's svn:externals.

Atom reaches one million active users

We have reached an exciting milestone: one million people have launched some version of Atom in the last month. That's three times the number of active users we had under a year ago at the one-year anniversary of Atom becoming completely open-source.

Graph of active users over Atom's history

Atom has been successful because of the community that has grown around it. The people that have contributed to Atom—that have given their time, expertise, feedback, suggestions, and insight—have helped Atom improve by leaps and bounds. We also hear of exciting or just plain cool things that people are doing with Atom all of the time—like MuleSoft's API Workbench, Jibo Robot's SDK tools, and Facebook's Nuclide.

It's not just companies that are coming up with interesting ways to use Atom. Some packages written by individuals that have caught our attention recently are:

  • Atomic Chrome - Syncs what you type in Atom to text inputs on web pages in Chrome so you never have to worry about losing what you wrote
  • Git Time Machine - Shows an interactive plot of the current file's Git commit history
  • Activate Power Mode - A fun package that infuses your typing with 💥power💥

All of us on the Atom team appreciate the work that the community has put in to our collaborative project. We're looking forward to what Atom will look like when we reach the next million users and hope that you are, too!

Introducing the GitHub Community Cast

At the heart of what makes GitHub great are the thousands of open source communities that build incredible things every day. The brand new GitHub Community Cast shines a light on these awesome projects and the people that make them.

Take a look inside a project, learn about their tools and workflow, discover where you can get involved, and get inspired for your own work. In addition to seeing behind the curtain on a great open source project, you'll also get news and updates from around the GitHub community.

The inaugural episode features an interview with Andy Miller from the Grav project, a modern flat-file CMS with some bold ideas. We also share some of the new features recently landed in GitHub and events going on around the GitHub community.


You can each episode from our SoundCloud page or subscribe to the podcast feed.

Learn from the experts: RSVP for workshops at Git Merge


At Git Merge—a conference for the Git community—you'll join developers who are committed to the future of Git. In addition to seeing an amazing lineup of speakers, attendees of all levels are invited to participate in a series of workshops led by the best Git trainers in the world. You won’t want to miss this unique opportunity to brush up on your skills while learning from the experts.

Workshops are 60-90 minutes and will take place concurrently with the general sessions. Take a moment to RSVP here to reserve a seat. Please note that you must also be registered for the main conference in order to attend any workshops.

Get out of (almost) anything with Git
One of the big advantages of version control is knowing you have a safety net in case anything goes awry. In this workshop, we'll explore common predicaments and discuss how to use the best tool for the job to get out of different tight spots. While the material we'll cover can help the beginner and the seasoned professional alike, attendees should have a basic working knowledge of Git and be comfortable on the command line.

Making the switch to Git LFS
If you're starting a new project, using Git LFS is easy. Converting an existing project, however, can present a few challenges. In this workshop, we'll adapt a sample project to use with Git LFS, Git's filter-branch command, and the BFG Repo-Cleaner. We'll also talk about the implications these approaches have on your project and your collaborators. Attendees should have a general understanding of Git internals and be comfortable working on the command line.

Mastering git-imerge
Git-imerge reduces the pain of merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts: those between the changes introduced by one commit from each branch. It also lets you interrupt, save, and publish in-progress merges—so you can test partially-merged code, or even collaboratively fix conflicts. In addition, it offers a straightforward method for preserving history while rebasing. This workshop will teach you how to use git-imerge to do all of this. It is intended for reasonably experienced users though it requires no expertise in Git.

Scripting Git
This workshop will cover several ways to write Git scripts. We will start by using the command-line client and Git's plumbing commands in shell scripts. Then we'll demonstrate how to write Git scripts in scripting languages, by using libgit2 and the various bindings to it (the workshop examples will focus on Ruby and Rugged). Attendees should understand the basics of Git internals.

Check out the full conference schedule here. Git Merge is happening on April 5, 2016 in New York City. We hope to see you there!

Creating a new contributor on-ramp

One of the most important elements of creating a strong community is shaping the new contributor experience. The on-boarding experience for new participants plays a huge role in how quickly someone can get up and running on your project. The most successful projects make this experience simple and accessible.

Getting someone started with their first contribution in a community typically follows a linear path, from discovery through appreciation. The environmental factors surrounding your project play the largest role in making that experience comfortable, empowering, and worthwhile.

The new contributor on-ramp

The on-ramp is a framework for growing your community. From getting your project noticed through celebrating a new contributor, building out each area will help your community thrive.

New Developer On-Ramp

At the beginning is a user that hasn't yet discovered your community. And at the end is a user that has made their first contribution to your project. Along their journey, the user usually goes through six steps of progress:

  1. Discover that the community exists and welcomes contributions from new members.
  2. Setup tools needed to build the project and create a contribution (e.g. editors, compilers, libraries, frameworks).
  3. Learn skills and knowledge to understand the codebase, contribution guidelines, and understand how their contribution will be reviewed.
  4. Identify tasks to work on, or know what kind of contributions would be welcome and worthwhile.
  5. Get help with the questions, queries, and sticking points they may have with their first contribution.
  6. Feel appreciated when they have successfully made their first contribution and at other key moments to know that the community is kind, supportive, and welcoming!

Within each of the six steps, there are many different things you could implement. This series will take a look at each step in turn, and for the rest of this post we'll delve into what you can do to help your project be discovered.


"If you build it, they will come" only works for Kevin Costner and baseball fields. For your project, the first step in building a community is making your project discoverable.

There are three goals for the discover step in the on-ramp:

  1. Welcome and inform new visitors about the community
  2. Establish your project as inclusive and welcoming of new contributors
  3. Show people how they can begin to contribute to the community

There are plenty of options on how to achieve these goals, below are a few of the basics that every community can use.

Create a file

Whenever you visit a GitHub repo, the contents of the README file is displayed underneath the file listing. It is a great opportunity to give a quick overview, including:

  • What your project is and what it does
  • How to build and run the project
  • Ask for new contributors
  • Provide details on how to get started, such as a file

By using Markdown you'll be able to format the README for easier viewing and link to resources for new contributors. Plus it'll look great!

Create a project website

While a is a good start, many projects can benefit from a comprehensive website. A full site gives the project a home for things like extensive guides, tutorials, and blogs.

Build the site from the perspective of a new user to your project:

  • Highlight the features of the project (with screenshots, if applicable)
  • How to install it
  • How to use it
  • Where to get in touch with the community
  • How to get involved in the community

The front page should have the most important information, like what the project does, how to get it, and how new contributors can join. Check out Bootstrap, Jekyll, or Electron for some ideas for your project site.

A fast way to get started with this is with GitHub Pages, which provides free hosting for a project website. When you create this site it will be publicly hosted at http://<username>

Engage on social media

Social media is a powerful tool for raising awareness about your project. Many people will follow the social media accounts of projects to keep up-to-date on news and announcements, it is also a great place to engage new contributors. Though tread lightly at first as social media can be time-consuming to maintain.

Twitter and Facebook are the best places to start. After registering the accounts, take some time to spruce up the profiles. Match the account design to your project website, and link back to it.

You can grow your community on social media by providing valuable and interesting content. Images and video are great additions to social posts. Be careful not to over-saturate your audience with too much content though. You should stick to:

  • Links to blog posts with updates, news, and other material
  • Videos with demos, screenshots of new features, and other visual content
  • Invitations for users to participate in issues, surveys, or other ways of getting engaged
  • News about growth of the project, partnerships with companies/organizations, and interesting use cases

A useful tool to simplify social media is Buffer. You can prepare your posts and content ahead of time, and it'll publish it on a schedule. By dedicating time to your social media strategy, you can free up your time for the week ahead.

Promote the community

There are many other ways to get the word out and highlight the work happening in your community. A few places you can start:

  • Organize Google Hangouts on Air to host an interactive show that gets the community involved. A bi-monthly show could be used to demonstrate new features, answer questions, or feature a new contributor.
  • Do interviews on podcasts, news website, and blogs to talk about the vision of the project and get people involved. It is often as simple as asking the site or podcast if they'd be interested in featuring your project.
  • Speak at conferences to show the great work going on in the project and provide simple steps for how people can get involved.

The new contributor on-ramp is a valuable framework to make the new user experience simple, empowering, and effective. These basic building blocks will setup your project to have a healthy and thriving community of contributors. We'll dive into the Setup Tools and Learn Skills steps in the next installment of the series.

Udacity joins the Student Developer Pack

Student Developer Pack + Udacity

Following up on the release of the Ruby Nanodegree program that we co-created with Udacity, we've extended our partnership to offer GitHub Student Developer Pack members one month of free access to any Nanodegree program. Pack members can choose from Android Developer, Front-End Web Developer, Data Analyst, or any of the 12 Nanodegree programs offered by Udacity.

In a Nanodegree program, you will:

  • Learn at your own pace from industry experts at Google, Facebook, and GitHub
  • Get access to coaches who provide you with personalized guidance, accountability, and code review
  • Create a portfolio of work to showcase your skills
  • Receive career support to help with your job search, and a guaranteed job when you sign up for Nanodegree Plus

The Student Developer Pack gives students free access to the best developer tools from 15 different technology companies like Stripe, Travis CI, and Unreal Engine. Now, with Udacity included in the pack, it's even easier for students to get started learning to program with professional tools.

Students, get your pack.

Kindly Closing Pull Requests

Getting your first pull request from an outside contributor on GitHub is an exciting experience. Someone cared enough about the problem you were solving to check it out themselves, change something, and contribute that change back to your project. When your project has a relatively small number of high-quality, desirable incoming pull requests it is easy to happily merge them.

Where things can become more difficult is when your project becomes more notable and the quality, desirability, or number of pull requests you receive causes difficulties. Now the positive feeling you had about the time people spent can be reversed; you don't want to reject someone's work when they have already spent the time to get it included.

Let's discuss some common types of pull requests that can be closed and how to do so in a way that encourages positive behavior in your community (rather than discouraging participation).

Close pull requests you will never accept

Sometimes outside contributors will submit pull requests for changes that you don't want to make to your project. For example, they may submit a feature you consider to be out-of-scope for your project. In this case the best option is to politely explain to users that, although you value their contribution, you are unwilling to accept it and close their pull request. Ideally, also explain to them and in a file how they can get a better indication in the future on what would or would not be accepted before they begin the work. The github/git-lfs project's file provides a good explanation of what features might be accepted.

Close pull requests you cannot accept

Hopefully you have continuous integration set up for your project to test pull requests before they are merged. In some cases, outside contributors may submit a change that breaks continuous integration tests and they may be unable or unwilling to make the changes required for the pull request to be merged. Another situation that can occur is that you request changes be made but the contributor never responds. In this case, it's better to close the pull request after a fair amount of time with no response or fix (e.g. a couple of weeks) and note this policy in a file (e.g. that merging a pull request requires passing tests). This does not need to be permanent; the contributor can always make more changes and submit another pull request in future.

Close pull requests on unmaintained projects

You may have created a project to solve a particular problem that you no longer have and open-sourced it just to share it with the community. In this case, consider documenting it in the README that you will not be accepting pull requests and close any that are submitted. Hopefully the clarification of project status in the README means the project will not receive any pull requests. If this is decided when you already have open pull requests: politely close them and explain why.

If your community has enough interest in maintaining the project they may fork it and decide to manage contributions there. A great final thing you can do with your project is to point people to the new project in the README and "bless" it as the new version of your project.

Close pull requests that turn sour

Discussions on pull requests can sometimes deviate from the original intent of the pull request and may even become unpleasant. In those cases, prioritize care for yourself and your community by closing (and optionally locking) pull requests. The original intent can be dealt with in another pull request.

For every pull request it's important to consider the users and maintainers of your project and ask yourself, "would merging this pull request make the project better or worse for them?". If you cannot answer "better" to this question: spend the time to help the outside contributor alter the pull request or submit another pull request for something you would be able to merge. Do not merge pull requests out of guilt for how much work the submitter has put in; you will only regret doing so in the long-term.

Although it's never nice to reject someone's work it's preferable to leaving pull requests open that you will never merge. Those pull requests will just hang over you and the contributor indefinitely. One of the indicators of a healthy project is its responsiveness to contributions, whether it is giving feedback, merging, or closing pull requests.

This post explains some of the reasons why you might want to close pull requests on your project and how to do so. We hope this helps project maintainers and contributors use pull requests to build software more effectively.

More code review tools

Effective code review catches bugs before they’re deployed, improves code consistency, and helps educate new developers. We’re adding new features to make code review on GitHub faster and more flexible.

Find what you’re looking for, faster

Pull requests with many changes sometimes require review from several people with different areas of expertise. If you’re a Ruby expert, for example, you might want to focus just on the Ruby code and ignore any changes made to HTML and CSS files. You can use the new files list to search by extensions like .rb, .html, etc. You can also filter by filename if you know what you’re looking for.

Find files you’re looking for, faster

More flexible review

Not all teams review code the same way. The most popular style on GitHub is reviewing all changes in a pull request at once, making the pull request the unit of change. Some teams choose to use a commit-by-commit workflow where each commit is treated as the unit of change and is isolated for review.

Page through commits easily

For teams using this style, you’ll now have access to the new commits list in the review bar which can help you quickly find the commit you want to review. We’ve also added pagination and new keyboard shortcuts to make navigating through commits in a pull request even easier. Use the ? key when viewing a pull request to view the list of keyboard shortcuts.

Use previous and next buttons to navigate through commits

View comments with more context

Every day, developers have interesting conversations and debates about code during the review process. These conversations can help new and future developers gain context quickly and better understand how and why a codebase has evolved over time. To ensure these conversations and the accompanying diffs are never lost we’ve made it easier to get deeper context on any line comment, even if it has been outdated by newer changes.

Use the “view outdated diff” button for more context

Pick up where you left off

While code review is essential for high quality code, it can be a long and tiring process, especially for projects with many incoming pull requests. It’s often most helpful to view just the new changes that have occured after you have reviewed a pull request, so we’ve added a timeline indicator to help you get to those changes, faster.

New changes are now marked in the timeline

Today’s changes are all about making code review on GitHub faster and more flexible for you and your teams. Check out the documentation for more information on working with pull requests. As always, get in touch with us for any questions or feedback. We’d love to hear how we can make code review even better.

Open Source Alley at OSCON: Call For Projects

OSCON is headed to Austin this year and we're bringing back the GitHub Open Source Alley. The alley features open source projects from across the community where they can chat with attendees, share their work, and get new contributors involved. OSCON runs from May 17 - 19th, 2016, in Austin and we'd like to invite you to apply to be a part of Open Source Alley.

GitHub Open Source Alley

As a featured project at one of the most popular open source conferences in the world, you'll get:

  • Table in Open Source Alley adjacent to GitHub's booth
  • Two complimentary OSCON passes for contributors and maintainers
  • Dedicated presentation time in the GitHub booth to highlight your project, deep dive into the code, and get people involved.

To be considered, you just need to complete the application by Friday, April 1st, 2016. The application form has the complete details and requirements for participating.

Can't wait to see you in Austin!

CodeConf LA tickets are now on sale

CodeConf LA June 27-29

CodeConf LA will converge June 27-29, 2016 in sunny Los Angeles for three days of unforgettable discussions.

This year’s event will focus on systems engineering projects, practices, and programs in the open source community. We'll explore topics ranging from systems programming practices to operating applications at scale over three days and 30+ sessions, lightning talks, and workshops.


Early Bird tickets are now on sale for $299. Grab yours before April 9th, when prices will go up by $100. While you're at it, consider purchasing a scholarship ticket, which will be granted to someone from an underrepresented community who would not be unable to attend otherwise.


June 27: A full day of workshops and training

June 28-29: 30+ Featured sessions, lightning talks and speaker Q&A

We believe that competing and complementary opinions lead to valuable insights. Over the course of the conference, there will be back-to-back talks exploring different subjects from contrasting perspectives, followed by a chance to participate in the conversation with other attendees.

If you have a subject for a session in mind or would like to give a talk, please submit a proposal. We'll be finalizing the agenda over the next few months, so follow along on and Twitter for updates.


If you're coming from out of town, stay nearby at the W Hollywood.

CodeConf is accessible from both LAX and BUR airports, and is just around the corner from the Hollywood/Vine LA Metro stop.

You won’t want to miss this educational and inspirational event, dedicated to the open source community. Hope to see you there!

Add Reactions to Pull Requests, Issues, and Comments

Every day, thousands of people are having conversations on GitHub around code, design, bugs, and new ideas. Sometimes there are complex and nuanced points to be made, but other times you just want to 👍 someone else's comment. We're adding Reactions to conversations today to help people express their feelings more simply and effectively.

While people have been able to include emoji in responses for a long time, using them as reactions resulted in a lot of noise. In many cases, especially on popular projects, the result is a long thread full of emoji and not much content, which makes it difficult to have a discussion. With reactions, you can now reduce the noise in these threads.

We decided to choose reactions that are relevant to the conversations people have on GitHub. 👍👎😄😕❤️🎉 cover the range of reactions our users typically express through comments on GitHub. We’re looking forward to seeing how the GitHub community uses this set of reactions.

Reactions are available on all Issues and Pull Requests on GitHub today. So go ahead…👍 or 🎉 to your ❤️s content.

Issue references and @mentions for GitHub Desktop

GitHub Desktop on both Windows and Mac now provides suggestions when mentioning team members, referencing Issues, and adding more 🎉 to your commit messages and Pull Requests.

Just as you would on the website, you can bring another collaborator into the conversation by prefacing their username with @, reference any Issue by hitting #, and include any emoji by putting : around its name. Happy shipping!

demonstration of Issue lookup, @ mentions, and emoji lookup

Upgrading your Textile posts to Markdown

A month ago, we announced that GitHub Pages had upgraded to Jekyll 3.0.

Starting May 1st, 2016, GitHub Pages will no longer support Textile. If you are currently using Textile (Redcloth) to author your Jekyll site, you'll need to convert your site to use Markdown instead.

Here are some tips for converting from Textile to Markdown.

Manual conversion

On sites with just a few Textile pages, editing those by hand may be the fastest way to convert to Markdown. Here are some of the most important changes.

Textile Markdown
headings h1. text # text
h2. text ## text
h3. text ### text
links "link-text (title)":url [link-text](url "title")
bullet lists * item * item
** nested item * indent nested item
numbered lists # item 1. item
## nested item 1. indent nested item
italics _italics_ _italics_
bold *bold* **bold**
code <code> code </code> code in backticks
blockquotes bq. text... > text...

For more details refer to the Textile docs and the GFM cheatsheet

Automated conversion from .textile to .md with pandoc

Users with many Textile files in their Jekyll Pages site can leverage pandoc, a utility for converting between different markup formats.

The tomd shell script uses awk and sed to overcome the biggest limitations of pandoc, filtering out the sections listed below, which pandoc doesn't recognize, and re-inserting them into the converted Markdown.

  • YAML frontmatter at the top of .textile files
  • {% highlight %} blocks
  • <notextile> blocks

To run tomd

  1. Install pandoc from or here.
  2. Download or clone tomd.
  3. Copy the tomd script and the two .awk files into your Jekyll project.
  4. Invoke the script with ./tomd from inside your Jekyll project folder.
  5. Validate the results.

The script will look for any .textile files in the _posts directory, convert them to .md, and leave backups of the original .textile files in a new directory called _old_posts. You can override the names of the directories with arguments to the script.

If everything works, you will see output like:


NOTE: This process may still produce some incorrect output, so check your results.

Known issues include:

  1. Lost CSS references e.g. from Textile .p(classname)
  2. Literal HTML mixed with Textile formatting e.g. <sup>"textile-link-text":url</sup>

Running under Windows

The latest version of pandoc for Windows can be downloaded from

In addition to pandoc, tomd requires a unix-y shell and utilities. The easiest way to get those for Windows is by installing the default set of cygwin utilities.

Before running tomd, use cygwin dos2unix and run it against the tomd file to remove extra linefeeds.

The output of running tomd in the cygwin shell should look very similar to the OSX output above.

Speakers Announced for Git Merge 2016


We are excited to announce our confirmed speakers for Git Merge 2016! On April 5th, 2016 at New York City's New World Stages (350 West 50th Street, New York City) we'll converge around a system that has become an integral part of all of our development workflows. This year’s Git Merge speakers will explore everything from scaling Git to Git optimizations. In addition to four training workshops by some of the best Git trainers in the world, you won’t want to miss these sessions:

Greg Kroah-Hartman, a Fellow at the Linux Foundation, will present on Linux kernel development. Hear his advice on how to stay sane while keeping up with development (hint: it’s Git). Greg is the author of two books about Linux kernel development, both free online, and has written many papers and articles about the Linux kernel.

Ryan Hodson is a marketer, writer, and web developer at CloudFlare and has consulted for technology companies including Atlassian and Syncfusion. Ryan's session on Git for Static Websites will explore the benefits of “going static” for everything from simple Jekyll blogs hosted on GitHub Pages to prime-time commercial marketing websites.

Emma Jane Hogbin Westby is a member of the field information services development team at United Nations Office for the Coordination of Humanitarian Affairs (UN-OCHA) and the author of the O'Reilly titles Git for Teams and Collaborating with Git. Her session on Teaching Git at last year’s conference was a huge hit, and we’re excited to welcome her back again in 2016.

Patrick Reynolds is a Git core contributor and a member of the GitHub systems team. If you’re curious about how we scale Git at GitHub, you won’t want to miss this session.

In addition to these exciting sessions, join us to hear talks by Spencer Krum (IBM), Tim Pettersen (Atlassian), Lars Schneider (Autodesk), Charles Bailey (Bloomberg), Sytse Sijbrandij (GitLab). John Haley & Hamid Shojaee (Axosoft) and Emily Xie (Wayfair).

We have plans for additional sessions, workshops, and an Afterparty at SpinNYC, so stay tuned as we roll out more information on and Twitter in the coming weeks. If you haven’t already, grab yourself a ticket before they sell out. We look forward to seeing you there!