We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.
-
First off, please be nice and follow the Code of Conduct.
-
If you’re new to Brevis, be sure to read our documentation to get a real understanding what is Brevis and its design principles.
The issue tracker is the only channel for bug reports and features requests, so please respect the following:
-
Do not use the issue tracker for personal support requests.
-
Do not derail or troll issues. Remember to follow the Code of Conduct.
-
Please close your own issue once it is resolved.
-
Please do search for duplicate or closed issues, before you open a new issue. Duplicate issues will be closed.
Guidelines for bug reports:
-
Use the GitHub issue search – check if the issue has already been reported.
-
Check if the issue has been fixed – try to reproduce it using the latest
master
branch in the repository. -
Isolate the problem – create a live example (e.g., on Codepen).
A good bug 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 experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs.
Example:
Short and descriptive example bug report title
A summary of the issue and the browser/OS environment in which it occurs. If suitable, include the steps required to reproduce the bug.
- This is the first step
- This is the second step
- Further steps, etc.
<url>
- a link to the reduced test caseAny other information you want to share that is relevant to the issue being reported. This might include the lines of code that you have identified as causing the bug, and potential solutions (and your opinions on their merits).
Brevis conforms to a strict set of design principles. Before proposing changes, consider alternative ways to achieve the intent behind a design.
If you’d like to propose a change, please look through and reference any existing issues that are related. Then, open an issue with the Enhancement label, links to related issues, and code demonstrating the proposal.
All code must meet the below style guide to keep consistency. Pull requests that fail to follow it will be rejected.
- Files must use UTF-8 character set encoding without BOM.
- Files must
use UNIX line endings (LF:
\n
). - Files must
end with a single empty line (i.e. LF:
\n
). - Indentation must use only tabs.
- Alignment when applicable, should use only spaces.
- If using tabs for anything, you must set the tab spacing to 4.
- Class selectors must follow the naming convention. However, there's no guarantee that the name will be accepted. We reserve the right to change it as necessary.
By contributing your code, you agree to license your contribution under the MIT License.