Skip to content
This repository has been archived by the owner on Sep 11, 2019. It is now read-only.

Latest commit

 

History

History
100 lines (72 loc) · 3.8 KB

CONTRIBUTING.md

File metadata and controls

100 lines (72 loc) · 3.8 KB

Contributing

We're so glad you're thinking about contributing to an 18F open source project! If you're unsure about anything, just ask — or submit the issue or pull request anyway. The worst that can happen is you'll be politely asked to change something. We love all friendly contributions.

We want to ensure a welcoming environment for all of our projects. Our staff follow the 18F Code of Conduct and all contributors should do the same.

We encourage you to read this project's CONTRIBUTING policy (you are here), its LICENSE, and its README.

If you have any questions or want to read more, check out the 18F Open Source Policy GitHub repository, or just shoot us an email.

Coding Standards

We adhere to PEP8 for Python code formatting. Before committing, please use a linter to ensure that your changes do not introduce any PEP8 warnings or errors. Most major code editors have a PEP8 integration, such as linter-pep8 for Atom.

For front end JavaScript, we use eslint to lint our source files. We recommend using an editor plugin (such as linter-eslint for Atom) to automatically lint JavaScript files. If you do not wish to use an editor plugin, you can run docker-compose run app yarn eslint from the command line.

CALC also provides a custom Django management command to run all linters and unit tests:

docker-compose run app python manage.py ultratest

You can run specific linters or tests via ultratest by specifying their name(s), for example:

docker-compose run app python manage.py ultratest flake8
docker-compose run app python manage.py ultratest flake8 eslint

Pull request guidelines

Please follow our Git Protocol and Code Review guidelines. Glen Sanford's thoughts on code reviews are also well worth reading.

Commit message style guide:

  • Write your commit message summary in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert.

  • Under the summary, start by explaining why this change is necessary, and add details to help the person reviewing your code understand what your pull request is about.

  • If the pull request fixes a GitHub issue, mention it at the bottom using GitHub's syntax, such as Fixes #123.

Example:

Load seed using before(:suite) in RSpec config

**Why**:
- Loading the seed in a `before(:each)` block results in an unnecessary
database call before every single test, slowing down the test suite,
and making development less efficient.

**How**:
- Use `before(:suite)` instead, since the data that is loaded is not
meant to change, and so that only one database call is made.
- To prevent the data from being wiped out after each spec, configure
Database Cleaner to ignore those static tables.

Fixes #123

Public domain

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.