Skip to content

Latest commit

 

History

History
80 lines (55 loc) · 4.05 KB

CONTRIBUTING.md

File metadata and controls

80 lines (55 loc) · 4.05 KB
Raw

Welcome!

We’re so glad you’re thinking about contributing to a Technology Transformation Services (TTS) open source project! If you’re unsure about anything, just ask — or submit your pull request anyway. The worst that can happen is we’ll politely ask you to change something. We appreciate all friendly contributions.

TTS is committed to building a safe, welcoming, harassment-free culture for everyone. We expect everyone on the TTS team and everyone within TTS spaces, including contributors to our projects, to follow the TTS Code of Conduct.

We encourage you to read this project’s CONTRIBUTING policy (you are here), its LICENSE, and its README. When you are ready to make a pull request, read our pull request process, which is a part of the Login.gov Handbook.

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

Pull request guidelines

Below are rules we strive to follow to achieve maintainable and consistent code.

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 is in response to a Jira ticket, include the ticket ID in the commit title (e.g. "LG-1234 Add the stuff to the thing")

Example:

LG-1235 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.

Additional notes on pull requests and code reviews

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

  • Keep pull requests as small as possible, and focused on a single topic
  • Once a pull request is good to go, the person who opened it squashes related commits together, merges it, then deletes the branch.

Everyone is encouraged to participate in code review. To solicit feedback from specific people, consider adding individuals or groups as requested reviewers on your pull request. Most internal product teams have a team handle which can be used to notify everyone on that team, or you can request reviews from one of the available interest group teams:

To request to join any of these teams, you can contact any existing member and ask to be added.

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.