Skip to content
This repository has been archived by the owner on Feb 24, 2018. It is now read-only.

Latest commit

 

History

History
51 lines (41 loc) · 3.91 KB

CONTRIBUTING.md

File metadata and controls

51 lines (41 loc) · 3.91 KB
Raw

Welcome

We're glad you're thinking about contributing to an 18F open source project! If you're unsure about anything, ask us — or submit the issue or pull request anyway. The worst that can happen is that we’ll politely ask you to change something.

We love all friendly contributions, and we welcome your ideas about how to make the FEC's online presence more user friendly, accessible, and elegant.

To ensure a welcoming environment for our projects, our staff follows the 18F Code of Conduct; contributors should do the same. Please also check out the 18F Open Source Policy GitHub repository.

If you’d prefer, you can also reach us by email.

Public domain

By submitting a pull request, you agree to comply with the policies on our license page.

Issues

We use GitHub issues to track user issues and team tasks. Whenever possible, we follow this outline:

  1. Goal: a quick blurb explaining the bug or what the issue should accomplish. What is the user need?
  2. Completion criteria: how we’ll know that this issue has been completed
  3. Tasks to completion:
    • Use
    • Markdown
    • Checklists
  4. Dependencies (optional): What other issues out there need to be completed before you can do this one? Include links to tickets with the dependency.
  5. For development issues, include: Unknown tasks or dependencies that need investigation The boilerplate tasks for each development issue

Commit messages

  • Good commit messages start with a verb, like “adds” or “changes” or “removes.”
  • Be sure to talk about the nature of the change you're making. Explain why the change is needed, rather than simply describing the bug or task it addresses.
  • If your commit resolves an issue, reference it in the commit messages. For example “fixes #555.” Read more GitHub guidance on closing issues via commit messages.
  • We encourage you to follow the 50/72 format.

Pull requests

  • Anyone may informally review a pull request and make comments or suggestions.
  • When a pull request is ready for review, label it plz-review.
  • Include a summary of all work and changes.
  • Use cc @username to notify a specific team member to review a pull request.

18F team processes

  • Use PEP8 as the coding standard for Python, but don't worry about fitting lines within 79 characters.
  • Create pull requests for all commits, even typo fixes.
  • Don't merge your own pull request. Ask a colleague to review your code and merge.
  • Pull requests contain some tests. Ideally they would contain decent test coverage.

18F team workflow

  1. Pull an issue from the current sprint only, please (unless there is an URGENT issue). Take an unassigned issue or re-assign an issue with the label "stealable." If a non URGENT issue comes up, but you want to prioritize it, coordinate with the PM or tech lead on slack.
  2. Before starting, write the dev issue checklist.
  3. While working, submit [WIP] pull requests liberally.
  4. Time boxing! If you have spent half the time of the estimated size of the issue and you're not sure that you're half-way finished, notify the tech lead or PM in slack. This isn't bad, we just like knowing what's up. :)
  5. Make sure your PR includes significant test coverage.
  6. Once you're done with your PR, notify the team in slack that your PR is ready for review. Do a review of someone else's PR. (Follow the above PR guidelines.)