Skip to content

Latest commit

 

History

History
47 lines (38 loc) · 2.5 KB

CONTRIBUTING.md

File metadata and controls

47 lines (38 loc) · 2.5 KB

Contributing to Akar

Thank you for your interest in contributing to this library.

If you wish to help out with things on our tasks list, or wish to contribute a new feature to the library, or wish to fix a bug, please create a Github issue, and start a discussion. If/once assigned, you can work on the issue independently, and submit a PR once you have made sure that the contribution guidelines for this project are met.

Tasks

  1. Migrate tests to a better testing library (potentially Midje). (#10)
  2. Rewrite some tests to achieve better consistency.
  3. Define new generally useful patterns.
  4. Write satellite libraries providing pattern support for popular libraries in the Clojure ecosystem.
  5. Add core.typed annotations. These should ideally come as a separate artifact.
  6. Release for ClojureScript. (#9)
  7. Improve error messages.
  8. Enable bindings in :or syntactic patterns.
  9. Migrate akar.syntax to clojure.spec. (Once it's stable.)
  10. General code improvements.

Guidelines

Pull Requests

  1. Always make the PR against the master branch. Except when it's a hotfix, in which case it should be made against the latest release branch.
  2. Add a prefix [WIP] to a PR's title until it's ready for review.
  3. Break the changes into small commits.
  4. Ensure a clean Git history before submitting a PR. Rebase judiciously.
  5. Ensure that the PR is up-to-date with the target branch.
  6. Include a reference to the relevant Github issue.
  7. Add a proper description of the work to the PR.
  8. Include failing tests which pass with the new changes.
  9. Include documentation where it makes sense.
  10. Add the change to the "Unreleased" section of CHANGES.md.

Commits

  1. Do not make more than one logical change per commit.
  2. Try to isolate pure formatting changes from actual changes in their own commits.
  3. The commit should have a descriptive subject line. Make sure that people can understand the commit when doing a git log --oneline.
  4. The commit message should obey the following formatting guidelines:
  • Separate the subject from body with a blank line.
  • Limit the subject line to 60 characters.
  • Capitalize the subject line.
  • Do not end the subject line with a period.
  • Use the imperative mood in the subject line.
  • Wrap the body at 72 characters.
  • Use the body to explain what and why, and if required, how.