All types of contributions are encouraged and valued. See the table of contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution.
First check existing issues to see if the question is already addressed, otherwise do the following:
- Open an issue.
- Provide as much context as you can.
- Provide project and platform versions if potentially relevant to the question.
- Apply the question label to the issue.
It's best to open an issue for questions, but if you have a sensitive question it can be directed to admin@mainuser.dev.
When contributing to this project, you must agree that you have authored the content, that you have the necessary rights to the content and that the content you contribute may be provided under the project license.
Any content that is sourced from or even inspired by code from another project (or forum, etc.) should be clearly commented to credit the author. It's encouraged to link the source for any non-original snippet used in this codebase, even in cases where there is no license or request for credit by the author.
A good bug report shouldn't leave others needing to chase you up for more information. Therefore, we ask you to investigate carefully, collect information and describe the issue in detail in your report. Please complete the following steps in advance to help us fix any potential bug as fast as possible.
- Make sure that you are using the latest version.
- Determine if your bug is really a bug and not an error on your side. If you are looking for support, you might want to check this section).
- To see if other users have experienced (and potentially already solved) the same issue you are having, check if there is not already a bug report existing for your bug or error in the bug tracker.
- Collect information about the bug:
- What did you expect to happen? What did happen?
- Stacktrace if available, any error messages.
- OS version, architecture, any additional user setup information.
- Version of the compiler, IDE, etc. if relevant.
- Can you reliably reproduce the issue? If so, list the steps. If not, describe the scenario in which it occured.
This section guides you through submitting an enhancement suggestion for Quack, including completely new features and minor improvements to existing functionality.
Enhancement suggestions are tracked as enhancements.
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a step-by-step description of the suggested enhancement in as many details as possible.
- Describe the current behavior and explain which behavior you expected to see instead and why. At this point you can also tell which alternatives do not work for you.
- Explain why this enhancement would be useful. You may also want to point out the other projects that solved it better and which could serve as inspiration.
- Make sure the enhancement is not better tracked as a bug, if it existing functionality that isn't working correctly, it's more suitable to be a bug. If it's existing functionality that is working sub-optimally, it can be opened as an enhancement.
See the main README of Quack for instructions on getting Quack setup locally.
Adding helpful Doxygen comments is the easiest way to improve the documentation. Adding code comments is also helpful, in places where the code is not self-descriptive or where additional context may be useful to a reader. Additionally, information can be added to the README of individual components.
Using AI to generate documentation is fine, but you should be sure that it is correct, helpful and not overly wordy before trying to merge it.
Adding a new repository to the red team repositories is allowed, but it should be helpful to the testing of the anti-cheat.
Style should be kept in-line with the component that is being worked on, some specific components have their own styleguides detailed in their README.
Gitignore is used as a whitelist in this project, see .gitignore for an example.
Changes can be made to style or project structure, but it is best to open an issue first detailing the planned changes to style or structure to make sure the changes would be accepted. The changes would also then need to be rolled out across the entire project, in order to remain consistent.
This guide is based on the contributing-gen. Make your own!