It’s been two years since the first cohort of student leaders became GitHub Campus Experts. In that time, more than 100 Campus Experts in 20 countries have made their campuses a better place to learn about technology. As GitHub Interns, they have built tech communities in Africa, organized inclusive conferences, and shipped amazing projects.
Now it’s your turn! If you’re a student—age 18 or older—using the Student Developer Pack, you’re eligible to apply for the next class of Campus Experts. Once accepted, you can access the Campus Experts training and develop skills in public speaking, workshop design, and community management. You will also receive training and mentorship from GitHub employees, opportunities to participate in exclusive events, and support to help you grow the developer community at your school.
At GitHub, we want to build experiences that make it as easy and intuitive as possible for all developers to do their best work.
We know that all development teams work a little differently. Since we can’t possibly consider all development practices, we turn to our community for feedback and data on how to improve our product. From this feedback, we plan and iterate on exciting new ways to support a variety of workflows.
But what about those smaller issues you find in existing workflows? What about the usability nitpicks that bother you daily but might not be a part of our bigger product initiatives? You—the wonderful and diverse GitHub community—have been telling us about some of these smaller frustrations for a while now, and we want you to know that we’re listening. We don’t think you should be frustrated by these “paper cuts” anymore.
Project Paper Cuts is dedicated to working directly with the community to fix small to medium-sized workflow problems, iterate on UI/UX, and find other ways to make the quick improvements that matter most.
GitHub has always had feedback channels that influenced our product, though we aim to be more open and transparent with this work. We’re not only listening to email, sales, support, and Twitter. We’re also looking at the wider GitHub community’s creation of self-organized ‘feature request’ repositories and browser extensions, as well as actively asking for feedback about the small things that irritate you the most.
One big source of inspiration for us has been the Refined GitHub browser extension. Full-time open source developer Sindre Sorhus has built a great browser extension that builds on and improves the GitHub experience, along with a fantastic community that has come together to discuss workflows and build their favorite features. Project Paper Cuts has taken inspiration from a lot of Refined GitHub’s additions, and we’re building some of the most-loved features right into GitHub itself.
To give you an idea of the scope of Project Paper Cuts, over the past month, we’ve shipped:
Internally, we’re fielding feedback with a spotlight on fixes that will have the most impact with the least process, friction, discussion and dependencies, and shipping as rapidly as we can. Most paper cuts will have a public changelog entry associated with them so you can follow along.
What we’re seeing and learning from the community by working on Project Paper Cuts will forever change how we work and build features. We will continue to let our community know that we hear them and that we’re building products that help all developers do their best work, faster.
The last time we wrote about an EU copyright proposal affecting software development, we explained that policymakers in Brussels responded when you took action. We’re fast approaching another vote on that proposal in the EU Parliament.
Here’s an update on the status of the negotiations, along with some ideas of how you can help Members of European Parliament (MEPs) understand why and how to protect software development. Activism by people concerned about the copyright proposal is part of why it hasn’t passed yet, so keep reading to learn how you can help shape the debate.
The EU’s copyright proposal has the potential to impact the way we develop software. There’s still time to make our stance heard on several key issues of the proposal before it becomes law:
Upload filters (Article 13): Automated filtering of code would make software less reliable and more expensive. Upload filters pose larger concerns—like censorship, free speech, privacy, and ineffectiveness—and are problematic for all kinds of content, including software code.
Text and data mining (Article 3): The copyright exception for text and data mining in the EU is too narrow, because it only applies to research organizations for scientific purposes on a not-for-profit basis. It would undermine the EU’s efforts on AI and machine learning, as well as software development in the EU that depends on AI and machine learning.
New right (ancillary copyright) for press publishers (Article 11): Requiring a license to post snippets of text that describe links would add overhead to anyone developing software for the web. It would also run counter to copyright exceptions that allow copying for certain purposes, like commenting on a copyrighted work.
We’re focusing on software because that’s where GitHub and software developers can speak with authority.
You may have heard that Parliament “rejected the copyright proposal” on July 5. Actually, Parliament voted against one of its committee’s proposals, but it didn’t permanently reject it. Instead, they voted to open the negotiations to all 751 MEPs, rather than primarily one committee.
That said, the rejection was significant because MEPs used a rare procedure to challenge the committee’s decision, and public advocacy against the proposal contributed to that.
Parliament will vote on September 12 based on amendments received by September 5. This time, it will be the full Parliament—with more than 700 additional MEPs potentially voting than when the committee voted on the proposal. And while they’re restarting negotiations, they’re not starting over completely. They’ll vote on amendments to the Commission’s initial proposal, which is the one that kicked off the idea of upload filters in the first place.
Whatever happens in Parliament, it’s important to keep in mind that there are three institutions involved in lawmaking in the EU: Commission, Council, and Parliament. If Parliament adopts a version of the proposal, it will enter into negotiations—or trilogues—with the Commission (based on its original proposal) and Council (based on its negotiating mandate).
But for now, all eyes are on Parliament to see what it might adopt.
Leading up to Parliament’s vote, a Copyright Week of Action is happening September 4-11. Each day in that week is dedicated to a different constituency. September 5 is for developers and open source software.
Because so many developers from the EU work in the San Francisco Bay Area, we’re hosting an event at our headquarters in San Francisco on that day for EU developers to encourage them to contact their MEPs and encourage developers back home to do the same.
Many MEPs aren’t familiar with software development or how this proposal can affect it. Developers are in an excellent position to explain to MEPs how essential open source software is to software development overall and to the countless sites, apps, and programs people rely on and enjoy.
It can be a lot to take in, so here are a few things you can share with your MEP to get started:
Ready to take action? Contact your MEPs and tell them to protect software development by:
If you aren’t a citizen of the EU, there are still ways to get involved and speak out for the developer community. Public advocacy has already shaped Parliament’s response, so share your thoughts on the copyright proposal on social media, raise awareness in your community and circles, and stay tuned to what happens next.
It’s going to happen one day. One of your students tries to merge one branch into another, and the dreaded error appears:
CONFLICT (content): Merge conflict in filename.ext Automatic merge failed; fix conflicts and then commit the result.
When changes in two branches overlap, Git shouts out for a clever human (like you or one of your students) to reconcile the differences. Even if you follow all the best practices of Git—communicate with your collaborators, pull in changes regularly, and make commits that are small, logical chunks—merge conflicts can still happen.
But merge conflicts don’t have to be scary for you or your students! In this post you’ll learn how to help students resolve them.
There are many situations when a merge conflict can happen—when a student pulls in changes from a repository, after they open a pull request, or when they push changes to another repository (there are other, less common situations too, like unstashing, cherry picking, and rebasing, that won’t be covered here). Let’s look at a few examples:
git pullto bring in their teammates’ work, they find that they’ve made overlapping changes to the same file.
Each of these situations leads to a merge conflict, but the process for resolving them is similar.
When Git encounters a conflict, it pauses whatever it was doing (like pulling changes) and asks you to resolve the conflict. To help you sort out the situation, Git inserts conflict markers into your files, showing you what your changes are and what your collaborators’ changes are. Conflict markers look like this:
<<<<<<< HEAD See also: [re docs](https://docs.python.org/3/library/re.html) ======= See also [re docs](https://docs.python.org/3/library/re.html) >>>>>>> master
In this example, Students Frank and Helen have both modified README.md. Frank’s change has been merged to master while Helen’s changes are on a local topic branch. Helen discovered this when she tried to merge the changes from master into her topic branch.
Helen looks closely at the conflicting line. Both students have made roughly the same change to the file by adding a link, but Frank’s change includes a typo. Helen decides to keep her version (HEAD) and discard Frank’s (master). She does this by deleting Frank’s changes and the conflict markers, like this:
See also: [re docs](https://docs.python.org/3/library/re.html)
When she’s done resolving the conflict, she runs
git add README.md to tell Git. Satisfied with her changes, she runs
git commit to finish the merge.
Consider another example, however, where Helen and Frank have both changed the same line in different ways. Before either of their changes, the file they’re both working on contains this line:
Don’t forget to run the `linter!`
In this example, Frank has expanded the sentence while Helen has added a filename. Helen pulls in the changes and sees these conflict markers:
<<<<<<< HEAD Don’t forget to run `linter.sh!` ======= Don’t forget to run the `linter` for :100: source style! >>>>>>> master
It doesn’t make much sense to choose one side over the other, so Git offers another option: write a new line that wasn’t in either side’s commit history. Like this:
Don’t forget to run `linter.sh` for :100: source style!
If there are more conflicts, then Git will insert conflict markers for each conflicting chunk it finds. Resolving many conflicts is like resolving one, except there are more conflict markers to tidy up. Walk through them one-by-one to resolve all the conflicts in all of the affected files. When you’re finished, add the files and commit.
Sometimes you’ll see a merge conflict in the context of a pull request.
A conflict in a pull request is like one on the command line. In a pull request, you can discuss with your collaborators how you plan to resolve merge conflicts and revise your branch.
The first option: the pull request author can update their branch. Since pull requests work with branches, you can often resolve a merge conflict by adding one or more commits to the incoming branch. For example, you can merge changes locally (e.g.
git merge master) and push the branch with the newly-added merge commit to GitHub.
If it’s a complicated conflict, you can discuss the best approach right from the pull request comments. Alternatively, you can amend your pull request (for example, by rebasing the incoming branch or amending a previous commit). This can be confusing at times, especially if there’s already been discussion in the comments.
Another option is to let the person accepting the pull request resolve the conflict while merging it. You can do this within the web interface using the GitHub editor or with the command line instructions GitHub provides—either way, it’s just like resolving a conflict with Git alone by choosing the resulting lines and removing conflict markers.
Resolving merge conflicts under a deadline might not be the best time for students to learn about them. Deliberately introducing merge conflicts in the classroom can help students when it comes time to handle them on their own. Check out Dr. Mine Çetinkaya-Rundel’s talk in which she shares how she teaches students Git skills, including resolving merge conflicts.
Want to learn even more about helping students understand and resolve merge conflicts? Check out the Campus Advisors learning module #3. This video course will help you learn more about group work, pull requests, and how to get your students comfortable with resolving conflicts.
Do you have an assignment you like to use to teach merge conflicts? Let us know in the GitHub Education Community.
Abhijeet Pratap Singh is a student at the Indian Institute of Information Technology in Tiruchirappalli, India. He was selected to be one of the Google Summer of Code (GSoC) students for the Probot project. In this post, Abhijeet recounts his experience working with the Probot Team at GitHub and what he learned about working with other developers on an open source project.
This spring, I was selected to participate in Google Summer of Code (GSoC), a program that pairs student developers with open source projects. I was placed with the Probot Team at GitHub. Probot is an open source framework used to build applications for GitHub based on NodeJS. These applications improve and automate your workflow while working on GitHub.
I’m a Computer Science and Engineering undergraduate at the Indian Institute of Information Technology. When I entered the Institute, I was very interested in knowing more about software. I explored different opportunities and found out about GSoC through Quora earlier this year.
I learned about Probot while researching the different projects partnering with GSoC. I had some previous experience working with bots and NodeJS and decided to try out applications built with Probot. I found the Probot community, a Slack community of developers who use Probot, which pointed me to the Probot Summer of Code and Probot’s GSoC project ideas. The project idea list helped me identify what project I should submit a proposal for.
I initially focused on the Twitter integration proposed in Probot’s ideas repo. After a few days of tinkering, I successfully developed my first Twitter integration bot. I recorded a screencast to log my progress with the bot and shared it with Brandon Keepers (@bkeepers), Jason Etcovitch (@JasonEtco), and Gregor Martynus (@gr2m).
I later submitted proposals for the Twitter integration and Weekly Digest projects when the student application period started. My proposal for the Weekly Digest project was accepted, and I became the Student Developer for Probot. The results were announced on April 23. I was so happy to see that my project was accepted and was really excited for this summer. Gregor Martynus (@gr2m) and Wilhelm Klopp (@wilhelmklopp) were assigned as my mentors.
GSoC kicked off in late April, and I spent more time exploring the community and its best practices. I also met my mentors over video conference. We discussed a plan to move forward with and implement our projects. Then we created the Weekly Digest repository in order to track progress.
The coding round began in mid May. I started by opening a few issues and pull requests, making some commits, and exploring GitHub’s REST API and GitHub’s REST API client for NodeJS. My mentors and I met weekly to go over the work I did and help out whenever I got stuck. It was a great way to discuss best practices, standards, and tools that developers use.
After working on the project, I got very close to a pre-release version of the app and released an alpha version of the Weekly Digest.
Here’s a GIF of the Weekly Digest app in action:
When you install the Weekly Digest in your (or your organization’s) repository, it curates the following data and publishes it as an issue:
The app, as the name suggests, generates these digests and publishes them on a weekly basis, typically on a Sunday. You can change the default configuration of the app by adding a .github/weekly-digest.yml file in your GitHub repository, which allows you to configure the publish date and the specific information included in the digest.
Becoming a software developer has been my dream ever since I was a kid. My mentors were happy to answer all of my questions and took time out of their busy schedules to meet with me. Through GSoC, I learned how a project is maintained and how developers work together to deliver solutions. And I got to develop a love for open source through my work with Probot!
I was really lucky to be guided by my mentors, Gregor Martynus (@gr2m) and Wilhelm Klopp (@wilhelmklopp). Special thanks to them, Brandon Keepers (@bkeepers), Jason Etcovitch (@JasonEtco), and the awesome Probot community for accepting me as a Student Developer for this year’s GSoC!