Skip to main content

​
Review Process

GitHub Desktop follows a structured review process to ensure quality and consistency across all contributions.
1

Open Pull Request

Contributor opens a pull request. If still in progress, create it in draft mode.
2

Mark Ready

When the pull request is ready, contributor marks it as ready for review.
3

Initial Triage

A reviewer team member adds the ready-for-review label and adds it to relevant release boards.
4

Reviewer Assignment

A reviewer with bandwidth assigns the PR to themselves and begins review.
5

Provide Feedback

Reviewer leaves line comments with suggestions or questions, then signals completion with a comment.
6

Address Feedback

Contributor responds to feedback, makes changes, and signals when ready for re-review.
7

Iterate

Steps 5-6 repeat until both parties are satisfied with the pull request.
8

Merge

Reviewer merges the pull request and deletes the branch (if applicable).
Merged contributions are first published to the beta channel (weekly) before being published to production (monthly).

​
Review Outcomes

GitHub’s review tools coordinate feedback with two possible results:
The contribution is ready to merge. No additional changes needed. The code meets quality standards and aligns with project goals.After approval, most contributions remain in this state for at least 24 hours before merging to allow the global team to provide feedback.
There are items to address before merging. The reviewer provides detailed feedback on what needs to be changed.Reviews may take multiple iterations, especially for large contributions. This is normal and ensures high quality and thorough discussion.
Reviews can take several iterations. Don’t be discouraged - the goal is to ensure quality and resolve all outstanding questions.

​
Review Assignments

The Assignee field indicates who “owns” the review process for a contribution.

​
Responsibilities

  • The assignee takes charge of the review process from start to finish
  • Other reviewers can add their feedback (large features often have multiple reviewers)
  • The assignee is ultimately responsible for seeing the PR through to completion

​
Workload Management

If a reviewer is overloaded or a review has stalled:
  • The reviewer may remove themselves from the pull request
  • This signals to others that help is needed
  • Another reviewer can step in to continue the process

​
Review Guidelines

​
Everyone Reviews

All team members are encouraged to review pull requests, even in unfamiliar areas of the codebase. This spreads knowledge across the team.
While everyone has domain expertise, sharing the review load helps:
  • Distribute workload evenly
  • Build broader understanding of the codebase
  • Provide diverse perspectives on changes

​
24-Hour Cooling Off Period

After approval, most contributions remain unmerged for at least 24 hours. Why?
  • The team is distributed globally across time zones
  • This ensures everyone has a chance to review and provide feedback
  • Prevents merging changes while some team members are offline
Exceptions:
  • Critical hotfixes that need immediate deployment
  • Time-sensitive changes with explicit team agreement

​
No Self-Merges Without Review

GitHub Desktop maintains a strong review culture. Contributors should not merge their own PRs unless there are exceptional reasons.
Dependency pinning affecting CI:
  • #2733 pinned a dependency that was breaking continuous integration by installing the wrong version
Critical packaging changes:
  • #4319 fixed an unexpected packaging change on the development branch that would affect all developers
Requirements:
  • Must be called out explicitly by the person merging
  • Must include explanation for bypassing review process
  • Should be truly exceptional circumstances

​
Stale Pull Requests

Reviewers monitor pull requests to ensure the review queue stays manageable.
1

14-Day Check

After 14 days with no response from the contributor or no new commits, the reviewer returns to the pull request.
2

Status Check

Reviewer asks if the contributor is still interested in working on the change and indicates they can reopen later if needed.
3

Resolution

If agreed to put on hold, or if no feedback is received after 3 days, the pull request is closed.
Closed stale PRs can be reopened later if the contributor has time to continue. This keeps the review queue focused on active work.

​
Contributing Tips

​
Before Submitting

  • Review the Code of Conduct
  • Check the roadmap to understand project direction
  • Search for related issues or pull requests to avoid duplication
  • For enhancements, open an issue first to discuss the approach

​
Reporting Bugs

Before reporting:
  • Search existing bug reports
  • Add a reaction to existing issues rather than creating duplicates
  • Add comments with additional information if relevant
When reporting:
  • Use the bug report template
  • Include build number and operating system version
  • Provide detailed reproduction steps
  • Add log files, screenshots, or other relevant information

​
Suggesting Enhancements

Before suggesting: When suggesting:
  • Use the feature request template
  • Use a clear and descriptive title
  • Provide step-by-step description of the enhancement
  • Explain why this would be useful to GitHub Desktop users
  • Include screenshots or examples if relevant
  • List other applications with similar features if applicable

​
Help Wanted

Look for issues labeled help wanted for good contribution opportunities. These issues:
  • Have low impact or known workarounds
  • Should be addressed
  • Have narrow scope and easy reproduction steps
  • Can be worked on independently
Comment on the issue to let the core team and community know you’re interested in working on it.

Build docs developers (and LLMs) love

Get started for freeTalk to us