Skip to content

Contributing

Brett Stevenson edited this page Jul 24, 2017 · 4 revisions

Contributing

The following is a set of guidelines for contributing to this project. These are not rules, use your best judgment and feel free to propose changes to this document in a pull request.

Code of Conduct

This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report any unacceptable behavior to [email protected].

How Can I Contribute?

For those looking to contribute to the development of the project, I recommend using the gulp watch command, to provide preprocessor compilation and live-reload functionalities.
Also, if you're looking for an easy way to contribute to this project but aren't sure where to start, I've created a list of minor bugs and/or issues to be fixed before the projects initial release, which you can find here.

Reporting Bugs

This section guides you through submitting a bug report for Atom. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.

  • Before creating bug reports, please check the existing issues as you might find out that one has already been created by another user.
  • When you are creating a bug report, please provide a clear and descriptive title.
  • Please include as many details as possible in your report. Remember, in order to fix the issue, we must first be able to reproduce it.
  • The use of images, GIFs, or any other form of media is not only allowed, it's encouraged.
  • Include any relevant details about your configuration and environment.

Enhancements & Feature Requests

Users provide the best insight for improving a product. So always feel free to suggest improvements, feedback, and give the developers an idea of what new features you'd like to see in the future.
Don't forget, this is one of the greatest benefits of open-source development!
If you'd like to submit an enhancement request, please include the following information:

  • Current project version (check that you are using the latest version)
  • How would this enhancement benefit most users?
  • Do you have any examples of other applications that feature this enhancement?
  • Relevant details about your configuration and environment.
  • Note: Don't forget to tag your post with the Enhancement label.

Pull Requests

Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub

  • Provide as much information as possible on the changes made to existing code.
  • Include thoughtfully-worded, well-structured commit messages and comments.
  • Include screenshots and animated GIFs in your pull request whenever possible.
  • When addressing an existing issue, please include an issue mention in the description of your pull request.
  • End files with a newline.
  • Avoid platform-dependent code on cross-platform applications.
  • Ensure that submitted code follows the style guidelines specified in the Styleguide below.

Styleguides

Commit Messages

  • Do your best to conform the tense to that of the existing commits. ("Add feature" not "Added feature" or vice versa)
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Consider starting the commit message with an applicable emoji:
    • 🎨 :art: when making aesthetic improvements
    • πŸ“ :triangular_ruler: when improving the format/structure of the code
    • 🐎 :racehorse: when improving performance
    • 🚱 :non-potable_water: when plugging memory leaks
    • πŸ“š :books: when writing docs
    • 🐧 :penguin: when fixing something on Linux
    • 🍎 :apple: when fixing something on macOS
    • 🏁 :checkered_flag: when fixing something on Windows
    • πŸ› :bug: when fixing a bug
    • πŸ”₯ :fire: when removing code or files
    • πŸ’š :green_heart: when fixing the CI build
    • βœ… :white_check_mark: when adding tests
    • πŸ”’ :lock: when dealing with security
    • ⬆️ :arrow_up: when upgrading dependencies
    • ⬇️ :arrow_down: when downgrading dependencies
    • πŸ‘• :shirt: when removing linter warnings

Code

  • Use spaces around operators
  • count + 1 instead of count+1
  • Use camelCase rather than underscore_case naming conventions
  • myFunction instead of my_function
  • Capitalize initialisms and acronyms in names, except for the first word, which should be lower-case:
    • getURL instead of getUrl
  • Provide comments for important or complex code
  • Conform your code to the existing styles to the best of your ability
  • Always check that your submission follows The Boy Scout Rule

(Adapted from the contribution guidelines of Atom)