Anisha Gupta is a recent graduate from Arizona State University, a Campus Expert, and developer workshop leader at events around the world. She joined the GitHub Developer Marketing team in January as a Developer Relations Intern and will be working through Summer 2018. In this post, Anisha shares how she was able to connect with diverse communities and find inspiration, while working remotely from ASU, by laser cutting contribution graphs.

Students don’t realize how much stuff they get for free—I didn’t until I was three months away from graduation. I’d just started an internship on GitHub’s Developer Relations team when I also discovered my university’s laser cutting lab. I passed by the lab daily but never entered because I didn’t even know what laser cutting was. It didn’t occur to me to try it out until I found the perfect design idea: contribution graphs. My contribution graph tells me what I’ve contributed to, how I contributed, and how often I worked on projects.

After talking to a mentor from the GitHub Team, Katrina Owen, I learned that she works daily on her open source project, exercism.io, and it takes 100 commits to turn a gray square green on her contribution graph. This was humbling and inspiring to hear as a recent graduate just about to enter the developer industry. That’s when I decided to laser cut @kytrinyx’s contribution graphs from 2013 and 2014 to remind myself of the effort one has to take to reach their goals. What started as something cool to have on my desk is now my source of inspiration as I look ahead to building my skills as a developer.

Getting started with laser cutting

I worked with my school’s lab manager to outline the steps for the laser-cut contribution graph I wanted to create. These are the steps I followed:

• Take a screenshot of the contribution graph you want to laser cut
• Use software that’s connected with your laser cutter (in this case, CorelDraw)
• Import the screenshot and convert it to a grayscale image
• Adjust the laser cutter’s settings to fit the wood density and thickness
• Click print

Once I started laser cutting more contribution graphs, including one I gave to Katrina, I set out to work on a project which allowed all GitHub users to create laser-cut contribution graphs. I consulted Ladies Storm Hackathons (LSH), a Facebook group that empowers women to collaborate and go to hackathons together. I got an overwhelming response from members who were excited to be part of the project.

But now I had to screenshot 20 different contribution graphs, adjust their sizes, and put them into one SVG file. My team suggested that I create an application to automate the process, so I set out to build an app that would let me create laser-cut contribution graphs and then place an order for business cards.

Building the application

A first attempt

I started out by reaching out to the GitHub Ecosystem team, and Katrina suggested I look at Puppeteer, a headless Chrome tool that renders and screenshots pages without having to pull up the browser itself. I found a Puppeteer sample on Glitch, which I used as the basis of my application. I dove into testing different methods within Puppeteer and was able to grab screenshots of contribution graphs from GitHub usernames. The few lines of code below show the two core methods that powered the application. It navigated to my profile page and took a screenshot based on the clip parameters I specified:

await page.goto('https://github.com/ani6gup');
await page.screenshot({path: __dirname+'/public/puppeteer.png', clip: {x: 320, y:630, width:660, height:100}});

However, the clip parameters were too specific. Each user’s contribution graph is placed at a different pixel based on a user’s descriptions and pinned repositories. In short, the application only worked perfectly with my profile.

Try out the application

Refining the app

I pair programmed with John Crepezzi, who introduced me to Ruby and various gems and packages such as Nokogiri, a parser of many file types, and Octokit.rb, a simple way to connect with the GitHub API. Nokogiri parsed the profile page into one HTML file that’s used to grab and filter the GitHub contribution graph into its own variable (and later converts it to an SVG file):

doc = Nokogiri::HTML.parse(contents)
doc.css('.js-calendar-graph-svg > g').first['transform'] = nil
graph = doc.css(".js-calendar-graph-svg").first

For the front and back side of the business cards, the app provides SVG templates and information from the GitHub profile page are used to fill in the name and handle. Octokit collects the profile information based on the username, and it only requires one line to connect to the API: user = Octokit.user(login). The end product is an application which requires only a username to create three SVG files and place them into a folder.

By automating this process, I was able to print out 28 business cards at one time. The 28 in the photo below are a combination of people who have helped me, community members from LSH, and my GitHub Team.

How I feel about contribution graphs now

This project showed me how communities can come together to expand on an individual’s idea to create something larger. Working with contribution graphs helped me find common ground with other GitHub community members. I learned about the projects they worked on and how they came to release, maintain, and make their projects thrive on GitHub. In the past, I was intimidated by profiles with green-filled graphs, but I realized that each person has their own story to tell, no matter what their graph looks like. And there are always opportunities to contribute more.

If you’re interested in expanding the projects you contribute to on GitHub and seeing more of those green squares, here are some resources that have helped me:

• Try GitHub Learning Lab if you’re new to GitHub
• Contribute to an open source project (it doesn’t have to be only code)
  • Learn more about contributing to open source
  • View or suggest edits to the GitHub Open Source Collection
• Participate in an open source themed event like (Hacktoberfest, 24 Pull Requests, or Rails Summer of Code
• Create a website in less than five minutes with GitHub Pages
• Journal every day in a private repo

If you would like laser cut your own business card or any design you had in mind, find a local makerspace to build things and become a part of a maker community.

We’ve made some changes to project automation that will provide you with more control when managing issues and pull requests in a project. Previously, issue and pull request cards behaved the same when they were added and moved across the board. Now you can specify different actions for them, like creating separate columns for in progress or reopened issues and pull requests.

Template updates

Simplify the process of managing bugs with the new “Bug triage” project board template. It features “To do”, “High priority”, “Low priority,” and “Closed” columns for better bug tracking.

The “Automated kanban” template has also been updated for automated workflows and now places newly-added pull requests to the “In progress” column. New issues will still appear in the “To do” column.

Changing your settings

With the feature flag enabled, anyone with write access can manually configure new issue and pull request automation options on existing projects.

To configure these settings in existing projects, click Manage Automation on the columns you wish to update. For new projects, access the changes by setting up a project with the “Automated kanban” template, or by clicking Manage Automation on any columns you manually create.

Read the documentation to learn more.

For the fourth year running, we’re kicking off Pride Month with limited-edition GitHub Pride and Trans Pride Shirts that help you show some pride and support the work of LGBTQ organizations while you do it.

Get your new favorite tee while you can. They’ll only be in the GitHub Shop until September 30.

Shop the shirts

Our new shirt design adds a little extra :heart: to your sleeve with retro ‘80s-inspired artwork in colors representing the pride and trans pride flags. The best part: For every shirt you buy, we’ll donate proceeds to some inspiring groups who are helping the LGBTQ community—find more information about their work below.

LGBTQ organizations you’ll be supporting

Jewish Family & Community Services (East Bay)

Rooted in Jewish values and historical experiences, and inspired by the strengths of the diverse communities they serve, Jewish Family & Community Services (East Bay) promotes the well-being of individuals and families by providing essential mental health and social services through every stage of life. Funds will be specifically marked for LGBTQ refugee services.

Trans Lifeline

Trans Lifeline works to end transgender suicide and improve overall mental health of transgender people through education, advocacy, and direct service. They empower transgender people to help one another and to shape our collective efforts by drawing upon our wealth of individual experiences.

Oakland LGBTQ Community Center

The Oakland LGBTQ Community Center is committed to supporting and enhancing the well-being of LGBTQ individuals, their families, and their allies.

Billy DeFrank LGBTQ Community Center

The Billy DeFrank LGBTQ Community Center provides community, leadership, advocacy, services, and support to the Silicon Valley’s LGBTQ people and their allies.

UCSF Alliance Health Project

The mission of the UCSF Alliance Health Project is to support the mental health and wellness of the lesbian, gay, bisexual, transgender, queer, and HIV-affected communities in constructing healthy and meaningful lives.

I am very excited to announce that Microsoft is acquiring GitHub and expect the agreement to close by the end of the year. While it will still take a few months to finalize, we wanted to share the news as soon as we were able.

When GitHub first launched ten years ago, I could have never imagined this headline. Git was a powerful but niche tool, clouds were just things in the sky, and Microsoft was a very different company. Open source and business, people said at the time, mixed as well as oil and water.

We disagreed. As developers, we knew this was a false dichotomy—we had been using open source software successfully in a business setting for a long time. What we really needed was an easier way to work with others regardless of whether the code was public, private, or something in-between. We wanted to do it using Git, we wanted anyone in the world to be able to join in, and we didn’t want it to cost a dime if it was open source. So we created GitHub.

Now, of course, things are different. Git is far and away the most popular version control system, clouds are mostly computers, and Microsoft is the most active organization on GitHub in the world. Their VS Code project alone is beloved by millions of developers, entirely open source, and built using GitHub’s Electron platform. Beyond that, today major enterprises regularly embrace open source. The world has realized how important happy, productive developers really are. And also, people have smartphones now.

What hasn’t changed, however, is our focus on the developer. From the beginning, we have been obsessed with building a product for the people using it. We want to make developers more productive and we want more people to become developers. From “Code to Cloud and Code to Edge”, GitHub’s mission is to help every developer—regardless of experience level—learn, code, and ship software effectively.

So as we look to the next decade of software development and beyond, we know it’s all about the developer. And as we’ve gotten to know the team at Microsoft over the past few years through collaborating on projects from Git LFS to Electron, we’ve learned that they agree. Their work on open source has inspired us, the success of the Minecraft and LinkedIn acquisitions has shown us they are serious about growing new businesses well, and the growth of Azure has proven they are an innovative development platform.

But more than that, their vision for the future closely matches our own. We both believe GitHub needs to remain an open platform for all developers. No matter your language, stack, platform, cloud, or license, GitHub will continue to be your home—the best place for software creation, collaboration, and discovery.

We both believe that software development needs to become easier, more accessible, more intelligent, and more open, so more people can become developers and existing developers can spend more time focusing on the unique problems they’re trying to solve.

We both see the growing need for developers and the growing importance of software in all facets of our lives.

And, most importantly, we both believe we can do greater things together than alone. Collaboration, after all, is at the heart of everything we do.

As part of this change, Nat Friedman will be taking on the role of GitHub’s CEO. We have been searching for a new CEO for some time and found in both Microsoft and Nat a partner we believe will strengthen and grow the GitHub community and company over the next few years. Nat has a ton of experience with software and the open source software community, having co-founded Xamarin and worked on numerous open source projects over the years, and is the perfect person to help GitHub grow and continue to make life better for developers.

As for me, I’ll be taking on a new role at Microsoft working closely with Nat and the team, and will share more details on that in the future.

I’m extremely proud of what GitHub and our community have accomplished over the past decade, and I can’t wait to see what lies ahead. The future of software development is bright and I’m thrilled to be joining forces with Microsoft to help make it a reality.

@defunkt
CEO & Co-Founder, GitHub

So you’ve given an assignment to your students in GitHub Classroom, either individually or in groups. But have you given a thought to how your students will work in a way that you can give them useful and instructive feedback?

One approach is linear: students make one commit a time on a single, master branch. In GitHub, teachers can give feedback on a sequential history by commenting on individual commits: view a diff, hover over any line, then click + to start commenting.

For students and teachers alike, this is a straightforward approach, but it’s a little limited. It doesn’t mirror the workflow software development teams use outside the classroom. And what if we want to work collaboratively, in a way that fits with the branch, commit, and merge tools that Git gives us? Then that’s where pull requests come in.

Pull requests build on the branching model of Git. A pull request is GitHub’s way of organizing the merging of two branches, whether it’s within a repository or in between forks. Pull requests make space for collaboration and conversation during the development process. In this post, we’ll walk through setting up a pull request workflow for submitting student exercises and leaving feedback.

Pull requests for individual exercises

By starting with pull requests, even for individual assignments, students can develop the skills and collaboration mindset that will help them when it’s time to work with others on a team. Pull requests allow students to experiment and document their processes and let educators give feedback on their progress. It works a bit like this:

1. The student clones their assignment repository to their local machine.
2. They start a new branch to work on solving a problem.
3. They work on their branch by committing their changes as they go, leaving a trail descriptive commit messages.
4. When they’re ready, the student opens a pull request. In the pull request message, they can describe what problem they’re solving, how they’re thinking about it, and why it’s a good solution.
5. The teacher responds to the pull request by:
   • Adding to the threaded discussion
   • Leaving line-by-line comments on the diff
   • Making a pull request review that combines an overview comment with contextual commentary

Compared to comments on commits, a pull request is a great place for discussion. Authors and reviewers can comment on specific lines, leave Markdown-formatted messages, or give emoji reactions 👍⭐. The student can even push new commits to the to-be-merged branch, amending the original pull request.

When the student and teacher are happy with the result, they can press the big green Merge pull request button, bringing the changes into the master branch (or another development branch). After a successful merge, you can tidy up by deleting the dangling branch with a one click.

Pull requests for group exercises

For group assignments, pull requests become an especially important tool for coordinating the work of many. In a collaborative workflow, pull requests open up new ways for educators to understand their students’ development. It works like this:

1. Each student clones the repository to their local machine and starts a unique branch to work on their part of the assignment.
2. The students work on their branches, committing changes and pushing their branch to the shared repository.
3. When each student finishes their part of the assignment, they start a pull request.
4. The students work together to review the proposed changes, discuss improvements or alternatives, and resolve conflicting changes arising from concurrent development.
5. When the students agree on a resolution, they merge each pull request.
6. After the assignment, the teacher leaves additional feedback in the pull requests.

As in individual assignments, pull requests give teachers the chance to peek into their students’ process. The repository’s own Insights tab can give a big-picture view of the students’ work, such as the number of open and merged PRs, frequency of commits, or who has contributed to the repository. A closer look at the pull requests themselves can show the team dynamic: how quickly students respond to PRs, what they say in comments to each other, and how they resolve conflicts.

Groups’ pull requests become a great place for teachers to give feedback, continuing the students’ conversations. Want to bring something to a specific student’s attention? An @mention—the @ symbol followed by a username—notifies the student directly. You can even comment on merged and closed pull requests, just like you would an open one.

Whether your students are working individually or in groups, pull requests are a great way for them to sharpen their workflow and for educators to guide their students. To learn more about using pull requests to work collaboratively, check out the Campus Advisors training module 3—it goes in depth on pull requests, resolving conflicts, and more—or scope out the GitHub Glossary to refresh your collaboration vocabulary. If you’re having any trouble wrapping your head around all this, check out how other teachers are learning about pull requests in the GitHub Education Community.

P.S. Have you been building up your assignment repositories over several semesters?

If so, chances are you have a pretty lengthy commit history by now. Here’s a workflow, inspired by Dr. Diosino, that gives students a clean commit history so they won’t be distracted by your past activity. Here’s how to do it:

1. Create a new repository. This one will be the pristine copy that your students will see.
2. Clone the new repository to your computer.
3. In your clone, pull the changes from the long-lived **repository. Run git pull **
4. Squash (abbreviate, in Git parlance) the history. Run git rebase –root –interactive and follow the instructions Git gives you to collapse many commits into one previous commit.
5. Push the new, abbreviated history to your new repository. Run git push origin.