1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
# Welcome!
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.
<a name="issues"></a>
## Have an Issue
If you run into problems with Smashing (or Dashing), please take these steps before
submitting an issue:
1. Check the [Troubleshooting Guide](https://github.com/Dashing-io/dashing/wiki#how-tos) in the wiki.
2. Use the [GitHub Issue Search](https://help.github.com/articles/searching-issues/) to check if the issue has already been reported.
3. Submit your issue to our Issue Tracker. Please provide as much helpful information as possible, preferably making use of a [reduced test case](https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases).
<a name="features"></a>
## Feature Requests
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](https://github.com/QubitProducts/dashing-contrib). If you
do create a third-party extension for Smashing, please add it [here](https://github.com/Dashing-io/dashing/wiki/Additional-Widgets#other-third-party-tools).
<a name="pull-requests"></a>
## Pull Requests
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.](https://help.github.com/articles/using-pull-requests/)
<a name="commit-msgs"></a>
## Git Commit Message Suggestions
* Consider starting the commit message with an applicable emoji:
* :art: `:art:` when improving the format/structure of the code
* :moyai: `:moyai:` when adding a new feature
* :wrench: `:wrench:` when dealing with the toolchain (Git, Travis, etc)
* :notebook: `:notebook` when dealing with docs
* :racehorse: `:racehorse:` when improving performance
* :penguin: `:penguin:` when fixing something on Linux
* :apple: `:apple:` when fixing something on Mac OS
* :bug: `:bug:` when fixing a bug
* :bomb: `:bomb:` when removing code or files
* :white_check_mark: `:white_check_mark:` when adding tests
* :lock: `:lock:` when dealing with security
* :arrow_up: `:arrow_up:` when upgrading dependencies
* :arrow_down: `:arrow_down:` when downgrading dependencies
|
