Thanks for getting involved! Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
Following these guidelines helps to communicate that you respect the time of the people managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue or assessing patches and features.
This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the project authors.
By submitting code or a feature request, you agree to allow the project owners to license your work under the terms of the project license.
This project uses labels to help organize and prioritize contributions. The labels are broken into three main types: Type, Status, and Priority.
When submitting a Bug Report, Pull Request, or Feature Request, please select an appropriate label from each of the three types. Contributions that don't observe this labeling schema are likely to be rejected.
Labels will be updated throughout the submission process to reflect the submission's overall status. For more information, please refer to this article.
This project uses templates for Issue and Pull Requests. Following the provided template helps the project maintainers have all the right details up front, which makes addressing feedback easier.
An Issue is a demonstrable problem that is caused by the code in the repository.
First, use the GitHub Issue search to check if the issue has already been reported—then, check if the issue has been fixed. Try to reproduce it using the latest master branch in the repository. Next, isolate the problem—ideally create a reduced test case and a live example.
A good Issue report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What browser(s) and OS versions experience the problem? What would you expect to be the outcome? Any guesses to a possible solution? All these details will help people to fix any potential bugs.
A Pull Request is a collection of changes submitted with the intention of being incorporated into the project.
Good Pull Requests, patches, improvements, new features, etc. are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.
When submitting a Pull Request, first use the GitHub Pull Request search to check if the request has already been submitted.
If it hasn't, please ask first before embarking on any significant Pull Request (e.g. implementing features, refactoring code, porting to a different language), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
Please adhere to the coding conventions used throughout a project (indentation, accurate comments, etc.) and any other requirements (such as test coverage).
A Feature Request is a new component or an enhancement to existing functionality.
Feature Requests are welcome. It's up to you to make a strong case to convince the project team of the merits of this feature. Remember that your request will be prioritized accordingly and not all requests can always be implemented in a timely fashion.
Before submitting, take a moment to find out whether your idea fits with the scope and aims of the project. Use the GitHub Issue and Pull Request searches to see if there is something similar to your propose feature being worked on already.
Use the GitHub Issues page to submit your Feature Request. Please provide as much detail and context in your request as possible.
A prompt is an idea for the site to use to help facilitate Inclusive Design thinking. The site's Issue Request Template and README's Contributing Guidelines have more info on what the project author considers in line with the project's overall direction.