Skip to content

documentation: update README and contributing guidelines #246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 20, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,41 @@ GitHub provides additional document on [forking a repository](https://help.githu
[creating a pull request](https://help.github.com/articles/creating-a-pull-request/).


### Committing your change

We use commit messages to update the project version number and generate changelog entries, so it's important for them to follow the right format. Valid commit messages include a prefix, separated from the rest of the message by a colon and a space. Here are a few examples:

```
feature: support VPC config for hyperparameter tuning
fix: fix flake8 errors
documentation: add README documentation
```

Valid prefixes are listed in the table below.

| Prefix | Use for... |
|----------------:|:-----------------------------------------------------------------------------------------------|
| `breaking` | Incompatible API changes. |
| `deprecation` | Deprecating an existing API or feature, or removing something that was previously deprecated. |
| `feature` | Adding a new feature. |
| `fix` | Bug fixes. |
| `change` | Any other code change. |
| `documentation` | Documentation changes. |

Some of the prefixes allow abbreviation ; `break`, `feat`, `depr`, and `doc` are all valid. If you omit a prefix, the commit will be treated as a `change`.

For the rest of the message, use imperative style and keep things concise but informative. See [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) for guidance.


### Sending a pull request

GitHub provides additional document on [creating a pull request](https://help.github.com/articles/creating-a-pull-request/).

Please remember to:
* Use commit messages (and PR titles) that follow the guidelines under [Committing your change](#committing-your-change).
* Send us a pull request, answering any default questions in the pull request interface.
* Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.

## Finding contributions to work on
Looking at the existing issues is a great way to find something to contribute on. As our projects, by default, use the default GitHub issue labels ((enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any ['help wanted'](https://github.com/aws/sagemaker-pytorch-training-toolkit/labels/help%20wanted) issues is a great place to start.

Expand Down
2 changes: 2 additions & 0 deletions README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@ SageMaker PyTorch Training Toolkit

SageMaker PyTorch Training Toolkit is an open-source library for using PyTorch to train models on Amazon SageMaker.

This toolkit depends and extends the base `SageMaker Training Toolkit <https://github.com/aws/sagemaker-training-toolkit>`__ with PyTorch specific support.

For inference, see `SageMaker PyTorch Inference Toolkit <https://github.com/aws/sagemaker-pytorch-serving-container>`__.

For the Dockerfiles used for building SageMaker PyTorch Containers, see `AWS Deep Learning Containers <https://github.com/aws/deep-learning-containers>`__.
Expand Down