Skip to main content

​
Welcome Contributors

Ryujinx welcomes contributions through pull requests, testing, and issue reporting. This guide will help you become an effective contributor to the project.
Before contributing, please read this entire guide to save time for both you and the maintainers.

​
Quick Reference

Code Style Guide

Follow Ryujinx’s C# coding conventions

Pull Request Guide

Understand the PR review process

​
Reporting Issues

Effective bug reports and feature requests help maintainers prioritize and fix issues faster.

​
Finding Existing Issues

1

Search first

Check the open issues to avoid duplicates
2

Add your feedback

If you find an existing issue, contribute your own experience to the discussion
3

Upvote issues

Use the 👍 reaction on the original post to help prioritize popular issues

​
Writing a Good Bug Report

A quality bug report should include:
Clearly explain what the problem is
Provide the smallest configuration needed to reproduce the issue:
  • A small homebrew application
  • Save file and reproduction steps for a specific game
  • Exact steps to trigger the bug
Describe what you expected to happen versus what actually occurred
Include system details:
  • OS/distribution
  • CPU model
  • GPU model and driver version
  • RAM capacity
Attach the log file from when the issue occurred:
  • Found in [Executable Folder]/Logs
  • Named chronologically
  • Is this a regression from previous versions?
  • Are there any known workarounds?
  • Any other relevant information
Use the Bug Report issue template when submitting bug reports.

​
Writing a Good Feature Request

Before submitting a feature request:
  1. Review existing feature requests for duplicates
  2. Familiarize yourself with the expected format
  3. Use the Feature Request issue template

​
Contributing Code

Maintainers merge changes that improve the project and meet quality standards.

​
DOs and DON’Ts

DO

  • Follow the coding style
  • Prioritize the existing style of files you’re modifying
  • Keep discussions focused; create new issues for tangential topics
  • Clearly state when you’re taking on an issue
  • Share your contributions on social media

DON'T

  • Submit PRs for style changes alone
  • Surprise maintainers with large PRs (discuss first on Discord)
  • Commit code you didn’t write without discussion
  • Modify licensing-related files or headers

​
Suggested Workflow

1

Create or find an issue

  • Skip this for trivial changes
  • Get agreement from the team for significant changes
  • State that you’re implementing it and request assignment
2

Fork the repository

Create a personal fork on GitHub if you don’t have one
3

Create a branch

git checkout -b mybranch
Branches isolate your changes and enable multiple PRs from one fork
4

Make and commit changes

5

Build with your changes

dotnet build -c Release
Ensure clean builds with no errors
6

Run dotnet format

dotnet format
Test and commit any formatting corrections
7

Create a pull request

  • Target the main branch
  • State what issue or improvement you’re addressing
  • Check that all CI checks pass
8

Wait for review

See the pull request guide for review details
9

Merge and celebrate

Once approved and all checks pass, your PR will be merged. Your change will be in the next official build!

​
Good First Issues

New to the codebase? Start with good first issues - these are straightforward tasks perfect for new contributors.

​
Commit Message Format

Follow this format based on A Note About Git Commit Messages: 
Summarize change in 50 characters or less

Provide more detail after the first line. Leave one blank line below the
summary and wrap all lines at 72 characters or less.

If the change fixes an issue, leave another blank line after the final
paragraph and indicate which issue is fixed in the specific format
below.

Fix #42
Factor commits appropriately - not too large with unrelated changes, and not too small with the same change applied multiple times.

​
CI Process

The continuous integration system automatically builds and tests all PRs.

​
Common CI Failures

Run dotnet format locally and commit the changes
Fix the compiler error in your PR
Investigate the test failure in your changes
A maintainer will manually restart the job

​
PR Feedback Process

Both team members and community members provide valuable feedback on pull requests.
Two Ryujinx team members must review and approve every PR before merge.

​
Understanding Review Comments

  • “LGTM, see nit” - The PR will be merged once minor feedback is addressed
  • “LGTM” - “Looks good to me” - approval granted
Be patient with reviewers who may need clarification on your approach. Clear, explicit feedback works best.

​
Copying Code from Other Projects

When including code from other projects, follow these rules:
1

Verify the license

The file must have a permissive license
2

Keep the license intact

Leave the original license text in the file
3

Update third-party notices

Add proper attribution to THIRDPARTY.md
Do not copy code without following these requirements. If unsure, file an issue or discuss on Discord first.

​
Next Steps

Build Ryujinx

Set up your development environment

Coding Style

Learn the C# conventions

Testing

Write and run tests

Build docs developers (and LLMs) love

Get started for freeTalk to us