Skip to content

Latest commit

 

History

History
108 lines (75 loc) · 4.65 KB

CONTRIBUTING.md

File metadata and controls

108 lines (75 loc) · 4.65 KB
Raw

Contributing to Riddler

The following is a set of guidelines for contributing to Riddler and its packages, which are hosted in the Organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Much of this is based on Atom's Contribution Guidelines.

Table Of Contents

Code of Conduct

Styleguides

Code of Conduct

This project and everyone participating in it is governed by the Riddler Code of Conduct. By participating, you are expected to uphold this code.

Styleguides

Issue Titles

We see each Issue as a request to change something in a project. Issues can be discussed and refined, and at some point may be accepted. If you would like to change something in the project, start with an Issue.

Once accepted an Issue is a command to change something in the project. Because of this all Issue titles use the imperative mood.

We try to stick to the following types of changes:

  • Add for new features
  • Change for changes to existing functionality
  • Deprecate for soon-to-be removed features
  • Remove for now removed features
  • Fix for any bug fixes

Git Commit Messages

Issues are requests (commands) to do something in a project and use the imperative mood. Some actor (most likely a person) will then perform the work needed to accomplish the request. Each portion of work will be recorded with a message stating what it does to the project using the simple present tense (active voice) where the commit is the subject.

We recognize this is different from what Git does.

Git Commit Summary

From Git Commit Guidelines:

Messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation.

  • Complete the sentance "This commit [Commit Summary]"
  • Use the simple present tense (active voice), NOT the imperative mood ("Adds feature" not "Added feature")
  • Capitalized
  • Limit to about 50 characters
  • More than a single word
  • Describe the changeset concisely
  • Does NOT end with a period
  • Does NOT reword what files are changed (this information is already present in the commit)
    • Do: "Documents project installation"
    • Don't: "Updates README"

Git Commit Message

  • Separated from Summary by one blank line
  • Use the simple present tense (active voice), NOT the imperative mood ("Adds feature" not "Added feature")
  • Limit lines to about 72 characters
  • Reference issues and pull requests liberally after the first line

Git Commit Template

This is a template Git Commit Message modified from Tim Pope's original template:

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit messages in the simple present tense (active voice):
"Fixes bug" and not "Fixed bug" or "Fix bug." This convention does NOT
match up with commit messages generated by commands like git merge and
git revert, but the messages make more sense when generating a
changelog.

Further paragraphs come after blank lines.

* Bullet points are okay, too

* Typically a hyphen or asterisk is used for the bullet, followed by a
  single space, with blank lines in between, but conventions vary here

* End by referencing issues and pull requests

Relates GH-1