First of all, thank you very much for taking the time to contribute to this community driven API! If you aren't already, feel free to take a peek in Helldivers 2 Developers Discord.
Let's run you through the process of contributing to the community API.
The first step to contributing is making sure that your contribution will be accepted. Opening a bug or feature request (that can potentially be transformed into a discussion) will ensure that the relevant maintainers are aware something will be worked on. This ensures that they aren't working on the same issue you are, or in the case of a feature request, that we are open to implementing the feature (see Why we might not accept all Pull Requests). Once a maintainer (most notably @dealloc and/or @lambstream) approves your change request, you can get started.
See Github's fork documentation.
(TODO: expand on all required dependencies, setup etc) Once you have cloned your fork or the API itself, run the following commands to initialize the local environment:
git submodule update .\src\Helldivers-2-Models\json
dotnet restore
dotnet build --no-restore --no-incremental
If you don't get any errors, that means your development environment is all set to get developing!
Open the Helldivers-2.sln
file in the root of the repository and you're good to go!
There's three pilars when it comes to coding conventions, formatting etc:
- .editorconfig is set up in the repository, if your IDE supports it you should install the required plugin to ensure your code is correctly formatted according to the configuration.
- Microsoft C# coding conventions write idiomatic C# and try to follow conventions from either Microsoft or the project if it deviates from a specific rule.
- dotnet-format we use
dotnet format
in our CI pipeline to ensure consistent formatting, line endings and syntax. Before submitting a pull request, make sure you rundotnet format
on your code.
Disagreements happen, discussions are perfectly fine (we encourage a healthy discussion even!), however you (and we) are to remain respectful at all times. While we try to listen to the community whenever possible, please keep in mind that 1. we do this in our spare time (for free, to boot!), and 2. we have the final say when it comes to decisions regarding the code that we maintain. See Code of conduct for more information on our expectations on the behaviour of our maintainers and community.
At the time of writing our project is licensed under MIT (you can read the 'plain English' version here). When you contribute to this project you accept that your code will also be licensed under MIT, and that you give full ownership of the contributed code to the helldivers-2/api project and it's maintainers. Under no circumstance are you entitled to compensation in any form, nor entitled to more involvement or authority over the code in this project, both contributed and otherwise.
There are three primary reasons we might choose not to accept your pull request (however it's not limited to these two);
- We don't accept pull requests that are cosmetic in nature (think formatting, whitespace, ...) we don't do this for the same reason the Ruby Rails project does not allow such changes, TLDR it adds noise and makes maintenance even more difficult than it already is.
- We don't accept pull requests with features we don't want/feel comfortable maintaining If you create an awesome feature that is rather complex, we might choose not to accept the feature. This is probably not related to the quality of your code (that's what PR's are for in the first place), but rather with the fact that after you've left, the maintainers still need to make sure it keeps working for as long as we don't sunset the feature. If your feature/PR would add too much of a burden on the maintenance we might choose not to accept it, regardless of how cool or convenient it is (sorry!).
- It falls outside the scope of this project This project aims to be a wrapper API around the official Helldivers API by ArrowHead studios. While there might be exceptions, any information not available in the API (or the game) falls outside the scope, the same goes for endpoints that might be considered dangerous (for example those that require authentication on the ArrowHead API).