Thank you for your interest in Dashing! This exceptionally handsome framework welcomes all input, but being stylish requires certain protocols be followed.
Below you will find a set of guidelines that will ensure the best outcome for you and Dashing.
If you run into problems with Dashing, please take these steps before submitting an issue:
- Check the Troubleshooting Guide in the wiki.
- Use the GitHub Issue Search to check if the issue has already been reported.
- Submit your issue to our Issue Tracker. Please provide as much helpful information as possible, preferably making use of a reduced test case.
Support requests should be directed to Stack Overflow.
Feature requests are welcome, but take a moment to consider whether your idea fits with the scope and aim of the project. A good rule of thumb is to apply the 80/20 rule: every feature should be useful to at least 80% of users. Adding in every possible edge case will only make it more difficult to understand, maintain, and hack on.
If you feel that you have a really amazing, super neato idea that doesn't quite fit with the core use of Dashing, it may be a good candidate for an external Gem which supercharges a project. An excellent example of this is dashing-contrib. If you do create a third-party extension for Dashing, please add it here.
Patches, improvements and new features are a fantastic help -- thank you!
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 may not be merged 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). All code submitted via Pull Request will be dicussed and critiqued in a respectful manner.
GitHub has excellent documentation on how to use Pull Requests.
- Consider starting the commit message with an applicable emoji:
- 🎨
:art:
when improving the format/structure of the code - 🗿
:moyai:
when adding a new feature - 🔧
:wrench:
when dealing with the toolchain (Git, Travis, etc) - 📓
:notebook
when dealing with docs - 🐎
:racehorse:
when improving performance - 🐧
:penguin:
when fixing something on Linux - 🍎
:apple:
when fixing something on Mac OS - 🐛
:bug:
when fixing a bug - 💣
:bomb:
when removing code or files - ✅
:white_check_mark:
when adding tests - 🔒
:lock:
when dealing with security - ⬆️
:arrow_up:
when upgrading dependencies - ⬇️
:arrow_down:
when downgrading dependencies
- 🎨