Thank you for your interest in Smashing! This project is a fork of Dashing, the exceptionally handsome dashboard framework. We're still in the process of transitioning, so please excuse the mess.
For general questions on new features, widgets, or ideas, please consider using the Gitter Chat Room. This way developers can maintain code-related issues in GitHub, and help users with users with simple usage or widgets questions in a more appropriate channel.
If you run into problems with Smashing (or Dashing), please take these steps before submitting an issue:
- Check the Troubleshooting Guide in the wiki.
- Ask in the Gitter Chat Room - please do not submit issues for support requests.
- 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.
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 Smashing, 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 Smashing, please add it here.
For general questions on new features, widgets, or ideas, please use the project mailing list.
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 discussed 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
- 🎨