Skip to content

Latest commit

 

History

History
63 lines (40 loc) · 2.79 KB

CONTRIBUTING.md

File metadata and controls

63 lines (40 loc) · 2.79 KB
Raw

Contribution Guidelines

This acs-engine Terraform provider project accepts contributions via GitHub pull requests. This document outlines the process to help get your contributions accepted.

Contributor License Agreements

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

NOTE: Only original source code from you and other people that have signed the CLA can be accepted into the repository.

Getting Started

Follow directions in the developer guidelines to get set up.

Support Channels

This is an open source project and as such no formal support is available. However, like all good open source projects we do offer "best effort" support through github issues.

GitHub issues:

Issues

Issues are used as the primary method for tracking anything to do with the terraform-provider-acsengine project.

When opening an issue, try to answer the following qeustions.

  1. Is this a request for help?
  2. Is this an issue or feature request?
  3. What happened?
  4. What did you expect to happen?
  5. How can you reproduce the problem?

How to Contribute a Patch

  1. If you haven't already done so, sign a Contributor License Agreement (see details above).
  2. Fork the desired repo, develop and test your code changes.
  3. Create branch with short name describing feature or bug you wish to contribute.
  4. Make sure to test your changes, and write or modify tests if they are needed for your change.
  5. When the branch is ready to review, push it to your fork on Github and open a new pull request.

When submitting the PR, try to answer the following questions.

  1. What is the PR and why do we need it?
  2. Which issue does this PR fix (if any)?
  3. What kind of testing did you do?

Your PR will be tested, reviewed, and changes may be requested before it can be merged.

Notes on labels coming soon.