GitHub and the United Nations free expression expert’s content moderation report

Earlier this month, we shared our contribution to a report about content moderation and free expression written by David Kaye, the United Nations Special Rapporteur on freedom of expression. That report is now available.

See the full report

While the report focuses on social media platforms that see large volumes of hate speech and misinformation, use automation to moderate content, and receive government takedown requests based on their Terms of Service, many of Kaye’s points are relevant to GitHub’s users.

For example, on how to respond to government takedown requests, the report cites GitHub’s contribution where it states:

Companies should ensure that requests are in writing, cite specific and valid legal bases for restrictions and are issued by a valid government authority in an appropriate format.

At GitHub, when we receive a government takedown request, we confirm:

  • that the request came from an official government agency;
  • that the official sent an actual notice identifying the content; and
  • that the official specified the source of illegality in that country.

Here are some other relevant points from the report.

Use human rights law as the standard

The report’s top recommendation to companies is to recognize human rights law as “the authoritative global standard for ensuring freedom of expression on their platforms.” As we note in our contribution:

GitHub promotes the freedom of expression in our policies and in our application of those policies to specific cases, consistent with international human rights law’s articulation of the right to freedom of expression and its limitations in the International Covenant on Civil and Political Rights (ICCPR).

The ICCPR allows limitations on free expression when provided by law and necessary, including for the respect of others’ rights or where the content constitutes harassment, abuse, threats, or incitement of violence toward others.

Engage users and be transparent in rulemaking

The report calls for companies to provide public input and engagement, and use transparent rulemaking processes. We develop the rules on our platform collaboratively with our community.

Restrict content as narrowly as possible

The report notes that companies can develop “tools that prevent or mitigate the human rights risks” caused when national laws or demands are inconsistent with international standards.

In these situations, we look for ways to comply that are the least restrictive on human rights—for example, by asking the user to remove part of a repository instead of blocking it entirely, and by geo-blocking content only in the relevant jurisdiction.

Avoid laws that require preventive monitoring or filtering of content

One of Kaye’s five recommendations for governments responds to a concern we raised in our contribution. We explained that measures like the European Union’s proposal to require upload filters for copyright infringement “are overly broad in their scope and, as applied to GitHub and our user community, could be so cumbersome as to prevent developers from being able to launch their work.”

The report noted that “automated tools scanning music and video for copyright infringement at the point of upload have raised concerns of overblocking,” and made this recommendation:

States and intergovernmental organizations should refrain from establishing laws or arrangements that would require the “proactive” monitoring or filtering of content, which is both inconsistent with the right to privacy and likely to amount to pre-publication censorship.

This recommendation is especially timely as the European Parliament’s Legal Affairs Committee advances toward its vote on the proposal on June 21.

Thanks to Special Rapporteur Kaye for his in-depth study of how human rights principles apply to content moderation on online platforms.

If you’d like to participate in the development of our policies, watch our site-policy repository, and look out for posts announcing new policies for public comment on our policy blog or follow our Policy Twitter account. To follow takedowns in real time, watch our gov-takedowns and DMCA repositories.

How to use pull requests in the classroom

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.

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.

Insights

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.

Join the GitHub Learning Lab Explorer Challenge

Learning Lab blog header

From May 23 to June 26, GitHub is hosting a challenge in the Community Forum where you can be recognized for leveling up your knowledge with GitHub Learning Lab.

To participate, visit lab.github.com and sign in with your GitHub account. Complete at least three courses, and head to the challenge page on the Community Forum for details on completing your submission.

If you’ve already taken GitHub Learning Lab courses and have completed the minimum three needed to participate, you can head over to the challenge page now to finish your submission today!

Those who complete the challenge by 11:59pm PT on June 26 will receive a limited edition badge on their Community Forum profile in recognition of their achievement and dedication to learning with GitHub. This badge is available only through this challenge.


Get recognized for leveling up your skills with GitHub Learning Lab. Join the challenge today.

Updated GitHub Privacy Statement and Terms of Service are in effect

Last month, we let you know of some updates to our Privacy Statement and Terms of Service and asked for help from our community. Thanks to everyone who commented and contributed feedback in our Site Policy repository, the updated Privacy Statement, Terms of Service, and Corporate Terms of Service are now in effect!

The updates

What this means for you

Updates to our Privacy Statement and Terms of Service are in effect as of today, May 25. You can accept them by continuing to use GitHub. Again, thank you so much to our user community for helping us improve our terms. Please let us know if you have any questions about the updates.

GitHub collaborates on how to promote human rights at RightsCon

RightsCon—an annual conference on human rights in the digital age—brought together more than 2,000 people from 115 countries last week in Toronto. On the first day of the conference, we joined non-profits, academics, and other tech companies for a session on working together to protect and promote human rights.

Alongside conversations on bias in artificial intelligence (AI) decision-making and cybersecurity capacity-building, we led the discussion on working with our community to develop the policies that govern the use of our site. In the face of public discourse on who should be deciding what speech is legal—and who should be held accountable for these decisions—we provided this example of how a platform can adopt rules through a transparent, democratic process.

At the session, we also highlighted several other ways in which our policy work promotes human rights, like freedom of expression and privacy. Some examples:

Free expression

To promote freedom of expression, we limit censorship by making sure requestors meet our detailed requirements for takedown requests and by limiting the impact of the takedown when possible. For example, we geo-block content that isn’t illegal in all jurisdictions and, when possible, ask users to remove parts of a repository that contain infringing content, rather than blocking an entire repository. In addition, we promote the right of access to information (related to the right to free expression) and transparency by publishing transparency reports and posting takedown notices in real time in our government-takedowns and DMCA repositories. We also described there (and at another RightsCon session) our work on the global implications of the EU’s copyright proposal on free expression.

In our submission to United Nations Special Rapporteur David Kaye’s upcoming report on content moderation and free expression, we note that our approach is consistent with international human rights law. As many speakers at RightsCon pointed out, those international standards are useful for companies looking for a baseline for evaluation that applies to users globally, without imposing one country’s norms on countless others.

Privacy

Millions of developers trust us with their data—and protecting their privacy is a top priority for us. We didn’t need to change the way we handle user data to comply with the EU’s General Data Privacy Regulation (GDPR), which recognizes data protection as a fundamental right. We are proudly in compliance with the GDPR ahead of the law’s deadline this Friday.

Anti-slavery and child labor

GitHub’s Statement Against Modern Slavery and Child Labor outlines the steps we take to make sure modern slavery and child labor are not in our business or supply chain. RightsCon participants were interested to hear how companies that aren’t typically associated with these abuses are taking steps to show how they prevent them, including by placing requirements on their suppliers.

Beyond these examples, a human rights perspective runs through much of our work, such as immigration, open source, net neutrality, and cybersecurity. Hopefully, this illustrates how important it is for tech companies to consider the human rights implications of so much of what we do.

Coming off the heels of an invigorating week of learning and collaborating at RightsCon, we look forward to continuing our work to keep the internet free, open, and secure, and to protect human rights.

Changelog

Subscribe

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more