This repository has been archived by the owner. It is now read-only.
Permalink
Fetching contributors…
Cannot retrieve contributors at this time
48 lines (36 sloc) 3.3 KB

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 cloud.gov page more user friendly, accessible, elegant, and useful.

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, please 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 and meets the intended need.
  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

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

  • 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.
  • Usually start with a verb. Like “added” or “changed” or “removed”.
  • Generally follow 50/72 format.
  • Reference a ticket number, where available, with "#555" if additional work is needed on the issue or “fixes #555” or any of the other keywords if the commit resolves the issue.
  • Be sure to talk about the nature of the change you're making instead of describing the bug or task. Explain why the change was needed if it is relevant.