Thank you for your interest in this project! What follows are some instructions for getting project support.
For both bug reports and feature requests, the main guidelines for submitting are in the issue template, so this document is mostly extra detail as applicable.
We will thank everyone who submits an issue to the project queue, and are likely to throw in some emoji reacts too. Beyond that, we reserve the right to close and reject any issue. In the vast majority of cases we will provide reasoning for closing in the comment thread before doing so.
Our target for an initial response to an issue is within 24 hours. Once an issue is open, the turn-around target for comments and pull requests goes to the one-week standard as outlined in the contributing documentation.
If you find a serious security vulnerability ("zero day"), please contact the project maintainer directly rather than submitting an issue into the queue. We take all security issues seriously, and will address and disclose all reports within 90 days. More information about security can be found in our security documentation.
All support requests and communication surrounding them is subject to our code of conduct. We're nice folks that will be nice to you by default.
Please search the issues before submitting a new issue, in case there's already a report/request that's the same or similar to the one you're looking to open.
If you do submit a duplicate issue, no worries; we will likely close your issue and provide a link to the existing one for continuing the thread.
The issues we accept and seek fall into three categories, outlined below: bug reports, enhancement requests, and support requests.
A bug report is an issue submitted to the project issue queue that a) explains how the project can be reasonably expected to behave, and b) demonstrates that the project does not behave that way.
Resolution of a bug report can be either a fix that makes the project work in the expected manner, or additional documentation within the project that explains why the reported behavior occurs, what to do if it's problematic, and ideally why it stays the way it is.
A good bug report issue should include the following:
- Which OS/Browser/stack and other applicable technologies are you using?
- What steps (URLs are great here whenever possible) can you follow (given 1) to replicate the problem?
- What is the expected result of following step 2?
- What happens instead?
- Are you willing to try and fix it yourself as a contributor?
Please tag bug reports with the 'Bug' label.
An enhancement request differs from a bug report in that it's an issue in the queue where a) the project does not have functionality or content to solve a particular user problem, but b) could in the future with some additional community work.
Resolution of an enhancement request can be a pull request that adds the new functionality or content, thereby completing the enhancing of the project. On the other hand, an enhancement outside of the project's agreed-upon scope or otherwise outside of the project's desired range of acceptability may be rejected with a note reflecting such.
When requesting an enhancement to the project, please provide some semblance of the following:
- What exactly should the enhancement be?
- Why should this be an enhancement to this project rather than the userspace?
- What other projects have similar functionality or content? What makes these implementations cool?
- Who benefits from this enhancement?
- What documentation needs follow from this enhancement?
- Is backwards-compatibility a concern?
- Is additional test coverage required?
- Are you willing to try and create the enhancement yourself as a contributor?
Please tag enhancement requests with the 'Enhancement' label.
In contrast to other open source projects, we're happy to field your questions and requests for general support in our issue queue!
A support request differs from both bug reports and enhancement requests in that a) the person reporting the issue is unable to make the project do a particular thing, but b) believes that the community can give them guidance to solve their problem.
Support requests are resolved when the user's question is answered. Ideally, the request also yields improvements to the project documentation so that future users have a source for solving their issue without having to ask.
Note: since support requests can take a lot of time and get repetitive, we cannot provide time guarantees for responses. We are also more likely to close support requests without necessarily resolving them, though we always strive to document the reason behind closing issues before doing so.
Please tag support requests with the 'Support' label.