1  # Contributing to Fork Awesome
  2  
  3  Looking to contribute something to Fork Awesome? **Here's how you can help.**
  4  
  5  ## Requesting new icons
  6  
  7  New icons mostly start as requests by the [Fork Awesome community on GitHub](../../issues). Want to request a new icon? Here are some things to keep in mind:
  8  
  9  1. Please be nice. Fork Awesome is a happy place.
 10  2. Please [search](../../search?type=Issues) to see if your icon request already exists. If a request is found, please add a 👍 reaction to that one.
 11  4. Please make requests for single icons, unless you are requesting a couple of strictly related icons (e.g., thumbs-up/thumbs-down).
 12  5. Please and thank you if you include the following:
 13    - Title your [new issue](../../issues/new?title=Icon%20Request:%20icon-) `Icon request: icon-name` (e.g., `Icon request: icon-car`).
 14    - Include a few use cases for your requested icon. How do you plan on using it?
 15    - Attach or link to a single color image or two that represent the idea you're going for.
 16    - Request concrete objects: it's harder to make an icon to represent happiness, it's easier to make a smiley face. ☺
 17  
 18  
 19  ## Adding a new icon
 20  
 21  Adding a new icon is a couple steps process that will require your attention and eyes for details. It might be a bit intimidating at the beginning, but should be easy to repeat once you've gone through it once or twice.
 22  
 23  0. Follow the [README.md](README.md#building-fork-awesome) to install the necessary tools.
 24  1. All icons are originally designed in SVG and fit in a grid (see `src/icons/icon-template-inkscape.svg` for a template for Inkscape).
 25  2. Most icons should fit a square that is centered vertically and aligned left in that template. (Try importing existing icons in that template to understand how they fit.)
 26  3. Design your icon in black only. No transparency. No gradient. Use simple shapes and forms. Note that it will be automatically transformed into a glyph. So if the design is complex, it might not show in the font as expected. Change a few things and try again if that happens.
 27  4. From the `src/icons` folder, use the `make` command to build the icon font. It will also generate a file called `src/icons/forkawesome/forkawesome-preview.html`. Open it with a browser and search your icon on the test page. This preview file will show you how your design behaves after conversion. It will also automatically associate a unicode code point for it. Be sure remember it.
 28  5. Once you are satisfied with your design and the preview of it. Add the icon name, unicode point and icon information at the bottom of the `src/icons/icons.yml` file. Look at other entries to see how it's done and to give it a proper classification.
 29  6. Once all this is done, commit your changes and make a pull request.
 30  
 31  Note : Please be considerate about maintainers' time and please
 32  [link your pull requests] to the icon request issue if it exists. You
 33  could use it within your commit message as well. This saves the
 34  maintainers extra effort in having to keep track of and close completed
 35  issues.
 36  
 37  [link your pull requests]: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
 38  
 39  ## Suggesting icon keyword addition/removal
 40  
 41  Icon filters are maintained by the [Fork Awesome community on GitHub](../../pulls?q=is%3Apr+label%3Adoc).
 42  
 43  If you feel that an icon
 44  
 45  * is missing keyword(s)
 46  * contains invalid keyword(s)
 47  
 48  please send a [PR](https://help.github.com/articles/using-pull-requests/) to the `master` branch.
 49  
 50  
 51  ## Reporting issues
 52  
 53  We only accept issues that are icon requests, bug reports, or feature requests. Bugs must be isolated and reproducible problems that we can fix within the Fork Awesome core. Please read the following guidelines to ensure you are the paragon of bug reporting.
 54  
 55  1. **Search for existing issues.** We get a lot of duplicate issues, and you'd help us out a lot by first checking if someone else has reported the same issue. Moreover, the issue may have already been resolved with a fix available.
 56  2. **Create an isolated and reproducible test case.** Be sure the problem exists in Fork Awesome's code with a [reduced test case](http://css-tricks.com/reduced-test-cases/) that should be included in each bug report.
 57  3. **Include a live example.** Make use of jsFiddle, jsBin, or Codepen to share your isolated test cases.
 58  4. **Share as much information as possible.** Include operating system and version, browser and version, version of Fork Awesome, etc. where appropriate. Also include steps to reproduce the bug.
 59  
 60  
 61  ## Key branches
 62  
 63  - `master` is the latest, deployed version
 64  - `gh-pages` is the hosted docs (not to be used for pull requests)
 65  
 66  ## Notes on the repo
 67  
 68  Fork Awesome's CSS, LESS, SCSS, and documentation are all powered by Jekyll templates and built before each commit and release.
 69  - `_config.yml` - much of the site is driven off variables from this file, including Font Awesome and Bootstrap versions
 70  - `src/doc/` - All edits to documentation, LESS, SCSS, and CSS should be made to files and templates in this directory
 71  - `src/icons/icons.yml` - all LESS, SCSS, and CSS icon definitions are driven off this single file
 72  
 73  
 74  ## Pull requests
 75  
 76  - Any changes to the docs must be made to the Liquid templates in the `src/doc` directory
 77  - Any changes to the styles must be made to the .less and .scss files in the `src/doc` directory
 78  - If modifying the .less and .scss files, always recompile and commit the compiled files
 79  - Try to share which browsers your code has been tested in before submitting a pull request
 80  
 81  
 82  ## Coding standards: HTML
 83  
 84  - Two spaces for indentation, never tabs
 85  - Double quotes only, never single quotes
 86  - Always use proper indentation
 87  - Use tags and elements appropriate for an HTML5 doctype (e.g., self-closing tags)
 88  
 89  
 90  ## Coding standards: CSS
 91  
 92  - Adhere to the [Recess CSS property order](http://markdotto.com/2011/11/29/css-property-order/)
 93  - Multiple-line approach (one property and value per line)
 94  - Always a space after a property's colon (e.g., `display: block;` and not `display:block;`)
 95  - End all lines with a semi-colon
 96  - For multiple, comma-separated selectors, place each selector on its own line
 97  - Attribute selectors, like `input[type="text"]` should always wrap the attribute's value in double quotes, for consistency and safety (see this [blog post on unquoted attribute values](http://mathiasbynens.be/notes/unquoted-attribute-values) that can lead to XSS attacks)
 98  
 99  
100  ## License
101  
102  By contributing your code, you agree to license your contribution under the terms of the MIT License:
103  - http://opensource.org/licenses/mit-license.html
104  
105  
106  ## Thanks
107  
108  Thanks to Bootstrap for their wonderful CONTRIBUTING.MD doc. It was modified to create this one.