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

Latest commit

 

History

History
90 lines (66 loc) · 4 KB

CONTRIBUTING.md

File metadata and controls

90 lines (66 loc) · 4 KB
Raw

Welcome!

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.

Participating in user research

We always welcome feedback from our users. For general feedback, please use the feedback form that appears in the footer of the Micro-purchase site.

Instructions for 18F team members

Check out on the onboarding docs for instructions on how to get going.

Instructions for contributors

See the local development docs for information on setting up the codebase and running tests locally or with Docker.

There are a few specific requirements that your pull requests must follow to be accepted into the project.

Testing and style compliance

We believe in a test-driven approach for this project and any new features must include corresponding tests. We use the Rspec framework along with other tools like Capybara to test everything from basic models up to multipage interactions with the site. All new code must be covered by tests or it will not be accepted. You can run rake spec to make sure all tests are passing before you submit your pull request.

We try to maintain a consistent style by using Rubocop, a style checker for Ruby code. We have relaxed some of the more stringent rules in a basic Rubocop configuration, so it should be easy to ensure your code meets our basic formatting rules. To check style, you can run rake rubocop to see any style offenses.

For front-end code, we use the jasmine framework to unit test user interactions and data visualizations. You can run rake jasmine and see if tests are passing at http://localhost:8888/.

Our Git Branching Philosophy

We are following a variant of the standard git flow approach for handling git branches. This means there are two main branches in the repository:

  • master - stable code deployed to production
  • develop - code in development that is periodically released to production by merging into master

Unlike git flow, there is no requirement to prefix any of your branches with type strings like feature/ or hotfix/, but you must submit any pull request against the develop branch. Pull requests against master will be rejected.

Preventing Technical Debt

One drawback to Rails' standard model-view-controller paradigm is that model objects tend to get cluttered over time with many different methods for all sorts of different reasons. We want to prevent this as much as we can. Read our document on technical debt to understand how things are organized.

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.