Skip to content

Latest commit

 

History

History
66 lines (54 loc) · 2.33 KB

CONTRIBUTING.md

File metadata and controls

66 lines (54 loc) · 2.33 KB

Lua Vermelha Contribution guidelines

There are several ways you can help make Lua Vermelha better. For example, you can:

  • open an issue to:
    • report a bug
    • create a feature request
    • suggest an improvement, e.g.:
      • code cleanup
      • better documentation
  • open a pull request to:
    • fix a bug
    • add a new feature
    • improve code quality/readability
    • add or improve testing
    • add or improve documentation
  • review and comment on open issues and pull requests

Opening an Issue

When opening an issue:

  • give the issue a short, meaningful name
  • provide as much detail as you can in the description, e.g.:
    • what you did when you found a bug
    • what platform/environment you were running on when you found a bug
    • how does some new feature improve Lua Vemrelha
    • why is a new improvement beneficial
    • what changes have to be made to accomplish the improvement
  • understand that the point of opening an issue is to start a discussion
  • expect questions and/or feedback

Opening a Pull Request

When opening a pull request (PR):

  • give the PR a short, meaningful name
  • write a detailed description of what your changes are and what they do
  • provide some justification for your changes, e.g.:
    • link to an open issue
  • write good commit messages:
    • the first line should be a clear, short (50 characters or less) description of what the commit changes, written in the imperative
    • the one-line description should be followed by a blank line, and then by a more comprehensive description of the commit
    • if appropriate, use GitHub flavoured Markdown in the longer description
    • the commit message should be wrapped at 72 characters
    • put relevant commit meta-data at the end of the pull-request, e.g.:
      • Fixes #1234
  • make sure any new code is sufficiently documented
  • make sure that documentation is clear and understandable
  • make sure that non-trivial code changes get tested
  • try to keep the PR and commits not too large (split them up if needed)
  • understand that the point of opening a PR is to get your changes reviewed
  • expect questions and/or feedback

Commenting on Issues and Pull Requests

When commenting on an open issue or PR:

  • be respectful
  • be clear so that others will understand you
  • when replaying to another person, @mention them so everyone knows who you're writing to