First off, thank you for considering contributing to Resultant! It's people like you that make the open-source community such a great place to learn, inspire, and create. Here are some guidelines that will help you along the way.
Resultant has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.
This section guides you through submitting a bug report for Resultant. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as much detail as possible.
- Provide specific examples to demonstrate the steps.
This section guides you through submitting an enhancement suggestion for Resultant, including completely new features and minor improvements to existing functionality.
- 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 much detail as possible.
- Provide specific examples to demonstrate the steps. Include snippets of code or screenshots if you think it will help clarify your suggestion.
Unsure where to begin contributing to Resultant? You can start by looking through beginner
and help-wanted
issues:
- Beginner issues - issues which should only require a few lines of code, and a test or two.
- Help wanted issues - issues which should be a bit more involved than
beginner
issues.
The process described here has several goals:
- Maintain Resultant's quality
- Fix problems that are important to users
- Engage the community in working toward the best possible Resultant
- Enable a sustainable system for Resultant's maintainers to review contributions
Please follow these steps to have your contribution considered by the maintainers:
- Follow all instructions in the template
- Follow the styleguides
- After you submit your pull request, verify that all status checks are passing
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
- Use camelCase for identifier names
- Use underscore for private fields
- Use four spaces for indentation
This section lists the labels we use to help us track and manage issues and pull requests.
While this list describes what each label represents, it also provides a rough guide to who will likely need to be involved in issues and pull requests with that label.
For more information on this process, see: GitHub's Issue and Pull Request labels.
Thank you for being part of this project! Your contributions make the open-source community such a fantastic place to learn, grow, and create.
Arda Terekeci