Skip to content

Latest commit

 

History

History
71 lines (42 loc) · 7.03 KB

CONTRIBUTING.md

File metadata and controls

71 lines (42 loc) · 7.03 KB
Raw

Guidelines for contributing

Thank you for your interest in contributing to AWS documentation! We greatly value feedback and contributions from our community.

Please read through this document before you submit any pull requests or issues. It will help us work together more effectively.

What to expect when you contribute

When you submit a pull request, our team is notified and will respond as quickly as we can. We'll do our best to work with you to ensure that your pull request adheres to our style and standards. If we merge your pull request, we might make additional edits later for style or clarity.

The AWS documentation source files on GitHub aren't published directly to the official documentation website. If we merge your pull request, we'll publish your changes to the documentation website as soon as we can, but they won't appear immediately or automatically.

We look forward to receiving your pull requests for:

  • New content you'd like to contribute (such as new code examples or tutorials)
  • Inaccuracies in the content
  • Information gaps in the content that need more detail to be complete
  • Typos or grammatical errors
  • Suggested rewrites that improve clarity and reduce confusion

Note: We all write differently, and you might not like how we've written or organized something currently. We want that feedback. But please be sure that your request for a rewrite is supported by the previous criteria. If it isn't, we might decline to merge it.

How to contribute

To contribute, send us a pull request. For small changes, such as fixing a typo or adding a link, you can use the GitHub Edit Button. For larger changes:

  1. Fork the repository.
  2. In your fork, make your change in a branch that's based on this repo's master branch.
  3. Commit the change to your fork, using a clear and descriptive commit message.
  4. Create a pull request, answering any questions in the pull request form.

Before you send us a pull request, please be sure that:

  1. You're working from the latest source on the master branch.
  2. You check existing open, and recently closed, pull requests to be sure that someone else hasn't already addressed the problem.
  3. You create an issue before working on a contribution that will take a significant amount of your time.

For contributions that will take a significant amount of time, open a new issue to pitch your idea before you get started. Explain the problem and describe the content you want to see added to the documentation. Let us know if you'll write it yourself or if you'd like us to help. We'll discuss your proposal with you and let you know whether we're likely to accept it. We don't want you to spend a lot of time on a contribution that might be outside the scope of the documentation or that's already in the works.

Guidelines for contributing code examples

Help us raise the bar for code examples, so that your code example will provide the most value it can to users.

When you submit a new code example to us, we strongly encourage you to include the following:

  • Provide a README.md file at the root level of your submission to help users save time and effort when they work with your example. At a minimum, your README.md file should describe what your example demonstrates, call out any prerequisites needed to run it, and then tell users how to run it. Here's a good example of a useful README.md file.
  • Write your code in a modular style to help users more easily copy and reuse it in their own solutions. By "modular," we mean that your code should accept inputs from the caller and return outputs to the caller. Provide comments in the code that describe these inputs and outputs. Also, don't hard-code input values in modularized code. Instead, provide these values through your unit tests, as described in the next point. Here's a good example of code written in a modular style.
  • Add some type of unit tests to help users more easily run your example. These unit tests can use hard-coded input values (or input values provided by the user) to call your example code. Here's a good example of unit tests that use hard-coded input values.
  • Add standard error or exception handling to your code to enable easier troubleshooting and recovery. Here's a good example of standard error/exception handling.

If your code example submission is missing any of these things, we might ask you to include them before we merge.

Although many older code examples in this repo don't contain all of these things, we're working to ensure that all newer ones do.

Finding contributions to work on

If you'd like to contribute, but don't have a project in mind, look at the open issues in this repository for some ideas. Any issues with the help wanted or enhancement labels are a great place to start.

In addition to written content, we really appreciate new examples for our documentation, such as examples for different platforms or environments, and examples in additional programming languages.

Code of conduct

This project has adopted the Amazon Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact opensource-codeofconduct@amazon.com with any additional questions or comments.

Security issue notifications

If you discover a potential security issue, please notify AWS Security via our vulnerability reporting page. Please do not create a public issue on GitHub.

Licensing

See the LICENSE file for this project's licensing. We will ask you to confirm the licensing of your contribution. We may ask you to sign a Contributor License Agreement (CLA) for larger changes.