Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
282 lines (186 loc) · 12.9 KB

CONTRIBUTING.md

File metadata and controls

282 lines (186 loc) · 12.9 KB
Raw

How to Contribute

We're so thankful you're considering contributing to an open source project of the U.S. government! 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 appreciate all friendly contributions.

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

Getting Started

Team Specific Guidelines

Building dependencies

The dependencies for this project are primarily OpenToFu providers. Required OpenToFu providers must be defined in every reusable module stored in terraform/modules/ Additional dependencies, especially those configured for

Building the Project

Workflow and Branching

Branches can be made directly off of the main branch and should be labeled with their associated Jira ticket/issue. Make any pull requests against the main branch.

Testing Conventions

Modules that require end to end evaluation should be represented in the services/tftesting/ path in a dedicated folder. These tftesting services can incorporate multiple services that depend on each other, such as a load balancer and an ECS service. Tftesting services should provision smoothly and destroy smoothly. If there are limitations to permissions, those should be addressed either by extending permissions or by noting strategies to accommodate restrictions.

Coding Style and Linters

In ToFu, our filenames use hypens, while our resource names use underscores. Our resource names are verbose, and rely primarily on constructed names based on 'app' and 'env'. Some exceptions are made to honor historical names using labels like "service_name_override". Stardard TF Linting is supported, and tofu fmt supports common patterns for code structure.

Writing Issues

Issues can be written with acceptance criteria, indicating what use cases must be met. Issues may also be populated with an expected path to fulfillment, as this will accommodate overarching architecture and design plans.

Writing Pull Requests

The following expectations apply to each PR:

  1. The PR and branch are named for automatic linking to the most relevant JIRA issue (for example, JRA-123 Adds foo for PR title and jra-123-adds-foo for branch name).
  2. Reviewers are selected to include people from all teams impacted by the changes in the PR.
  3. The PR has been assigned to the people who will respond to reviews and merge when ready (usually the person filing the review, but can change when a PR is handed off to someone else).
  4. The PR is reasonably limited in scope to ensure:
    • It doesn't bunch together disparate features, fixes, refactorings, etc.
    • There isn't too much of a burden on reviewers.
    • Any problems it causes have a small blast radius.
    • Changes will be easier to roll back if necessary.
  5. The PR includes any required documentation changes, including README updates and changelog or release notes entries.
  6. All new and modified code is appropriately commented to make the what and why of its design reasonably clear, even to those unfamiliar with the project.
  7. Any incomplete work introduced by the PR is detailed in TODO comments which include a JIRA ticket ID for any items that require urgent attention.

see our .github/pull_request_template.md for more examples.

Reviewing Pull Requests

When you submit a pull request on GitHub, it will be reviewed by the project community (both inside and outside of github.cms.gov), and once the changes are approved, your commits will be brought into github.cms.gov's internal system for additional testing. Once the changes are merged internally, they will be pushed back to GitHub with the next sync.

This process means that the pull request will not be merged in the usual way. Instead a member of the project team will post a message in the pull request thread when your changes have made their way back to GitHub, and the pull request will be closed.

The changes in the pull request will be collapsed into a single commit, but the authorship metadata will be preserved.

Shipping Releases

Definitions for breaking changes will vary depending on the use-case and project but generally speaking if changes break standard workflows in any way then they should be coordinated with affected teams.

The resources provided in cdap are provisioned on a rolling schedule and do not adhere to formal release timelines.

Any major issues can be communicated and coordinated through slack at #cdap-users.

cdap module versions are versioned against Git commit hashes and can be references with ?ref=. New versions should also be built with backwards compatibility in mind.

Policies

Open Source Policy

We adhere to the CMS Open Source Policy. If you have any questions, just shoot us an email.

Security and Responsible Disclosure Policy

Submit a vulnerability: Vulnerability reports can be submitted through Bugcrowd. Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.

For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see SECURITY.md.

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 or issue, you are agreeing to comply with this waiver of copyright interest.