Pull Requests¶

Before you start¶

• Trivial fixes (typos, small bug fixes, one-liner corrections) — go ahead and open a PR directly. These are the most likely to be accepted quickly.
• Anything non-trivial (new features, API changes, refactors, large additions) — open an issue or GitHub Discussion first and get agreement from a maintainer before writing code. This is important. We have had to decline well-intentioned PRs that conflicted with ongoing work or didn't align with the project's direction, and that is a bad experience for everyone. A quick conversation upfront saves you from investing time on something that may not be merged.
• Search existing PRs and issues to avoid duplicate effort.

Forking and cloning¶

Most contributors will work from a fork. There are two ways to get started:

Option A: GitHub CLI (recommended)¶

The gh CLI handles fork creation, cloning, and remote setup in one step:

gh repo fork reactiveui/<repo-name> --clone
cd <repo-name>

This creates your fork on GitHub, clones it locally, and sets up origin (your fork) and upstream (reactiveui) remotes automatically.

Option B: Web UI + command line¶

1. Click Fork on the repo's GitHub page
2. Clone your fork:

   git clone --recursive https://github.com/<your-username>/<repo-name>.git
   cd <repo-name>
   git remote add upstream https://github.com/reactiveui/<repo-name>.git
   

Option C: GitHub.dev or Codespaces¶

For documentation or small code changes, press . on any repo page to open it in github.dev, or use GitHub Codespaces for a full cloud dev environment with build support.

Keeping your fork up to date¶

git fetch upstream
git rebase upstream/main

Or use the Sync fork button on your fork's GitHub page — see GitHub's syncing docs.

Making changes¶

1. Create a branch from main:

   git checkout -b my-fix-branch main
   

2. Make your changes:

   • Follow the code style guide
   • Include tests for new behaviour or bug fixes
   • Ensure the build and all tests pass locally (dotnet build && dotnet test from src/)

3. Commit using conventional commits:

   fix: correct nullable handling in WhenAnyValue
   

4. Push to your fork and open a PR:

   git push origin my-fix-branch
   

   Then open a PR against reactiveui/<repo-name>:main — GitHub will prompt you when you visit your fork.

What happens next¶

• CI runs automatically — build, tests, and code analysis must all pass.
• A maintainer will review your PR. We may suggest changes — push additional commits to your branch.
• Once approved, a maintainer will squash-merge your PR.

API surface changes¶

If your change modifies the public API, approval test files will need updating. See building & testing for details. Include the updated *.approved.txt files in your PR.