One of the easiest ways to contribute is to participate in discussions on GitHub issues. You can also contribute by submitting pull requests with code changes.
Start a discussion on the repository issue tracker or join us on slack.
Before reporting a new issue, try to find an existing issue if one already exists. If it already exists, upvote (👍) it. Also consider adding a comment with your unique scenarios and requirements related to that issue.
If you can't find one, you can file a new issue by choosing the appropriate template here.
We are always happy to see pull requests from community members both for bug fixes as well as new features.
We have marked issues which are good candidates for first-time contributors, in case you are not already set on working on a specific issue.
- "Good first issue" issues - we think these are a great for newcomers.
- "Help wanted" issues - these issues are up for grabs.
Before you spend time writing code, make sure of the following things:
- You have commented on the related issue to let others know you are working on it
- You have laid out your solution on a high level and received approval from the maintainers, if you are tackling a bigger change
After this you can fork our repository to implement your changes. If you are unfamiliar with forking, be sure to read this guide first.
To get started with the codebase, see How to launch and build the solution.
Before submitting a pull request containing your changes, make sure that it checks the following requirements:
- You add test coverage following existing patterns within the codebase
- Your code matches the existing syntax conventions within the codebase
- You document any changes to the public API surface (Learn more)
- Your pull request is small, focused, and avoids making unrelated changes
If your pull request contains any of the below, it's less likely to be merged.
- Changes that break backward compatibility
- Changes that are only wanted by one person/company
- Changes that add entirely new feature areas without prior agreement
- Changes that are mostly about refactoring existing code or code style
Follow this guide to submit your pull request. Be sure to mark it as draft if it is in an early stage.
Core contributors will review your pull request and provide feedback.
We use Nuke for build automation.
To work on Hot Chocolate, you will need .NET 7, Node 14, and Yarn 1.x.
After cloning the repository, run init.sh or init.cmd, which are located in the repository's root. The script files will create the src/All.sln, which can be used to develop in Visual Studio 2022 and higher or Rider 2021.3 EAP or higher. It will also restore the packages for the documentation.
Other more focused solution files exist if you want to narrow in on a particular part of the platform. The smaller solution files are great when working with VSCode.
The documentation is located in the website directory and can be started with yarn start.
There are other available commands too. As set up in the .build directory.
We use Markdownlint to check markdown formatting and cSpell for spelling. We have GitHub actions to check these for PRs, but if you'd like to check locally, you can:
- Install cSpell:
npm install -g cspell - Install the markdownlint CLI:
npm install -g markdownlint-cli. - For spellcheck, run
cspell --config ./cSpell.json "website/src/**/*.md" --no-progress - For markdown linting, run
markdownlint "./website/src/**/*.md" --disable MD013