Skip to content

Latest commit

 

History

History
40 lines (24 loc) · 3.63 KB

CONTRIBUTING.md

File metadata and controls

40 lines (24 loc) · 3.63 KB
Raw

Contributing

  • If your contribution is minor, such as a bug fix, open a pull request.
  • If your contribution is major, such as a new custom extension starter kit or a new web chat extensibility and customization code example, start by opening an issue first. Others can then weigh in before you commence any work to make sure the IBM team is not already working on something similar and to make sure that your PR will be approved when the work is completed.

Intellectual Property

We take intellectual property seriously. We need to be sure of the provenance of your contribution and that we have the ability to include it in our project and redistribute it under our open source license. When you submit your PR, you're asserting that you have authored all of the code in the PR and that you have the right to contribute it to our project.

If your code is part of an IBM offering or is part of an IBM contracted services engagement please include this information in the issue and PR. It may not be an issue, but because this code can end up in our commercially licensed cloud and on premise offerings, we need to be sure of the provenance of your contribution and that we have the ability to use it and redistribute it.

Submittion Guideline

  1. Fork the repo
  2. Create a local branch for your change, e.g. git checkout -b my-new-feature-branch
  3. Test your changes
  4. Open a pull request

Additional Guidelines

The assistant-toolkit repository contains a variety of project types. Please refer to the following additional guidelines for contributing for selected project types.

  1. Web chat extensibility and customization example contributing guidelines
  2. Custom extension starter kit contributing guidelines

Pull Request Process

Once you have implemented a change and have created a PR to the repo, the review of the PR will follow this process.

  1. The code author should assign a reviewer using the "Assignees" field (do not use the "Reviewers" field) of the PR. The assignee is the person who is currently responsible for taking action on the PR.

  2. Do not push any more commits to the PR while it is assigned to a reviewer without talking to the reviewer first. This can mess up any comments that the reviewer may be in the process of making.

  3. The reviewer will review the changes and provide appropriate feedback. If there are changes the reviewer would like the author to make, the reviewer will request those changes using the "Request changes" option on the review in the PR and then assign the PR back to the author.

  4. If you are responding to comments made by a reviewer you can respond in one of two ways. If you simply make a requested change and don't have any comments to add or explanations to make, just click "Resolve conversation" to resolve the conversation. If for some reason, you decide not to make a change requested by a reviewer, you should add a comment explaining why not and leave the conversation unresolved. If you do make a requested change but also want to add a comment with some explanation, then add the explanation and also leave the conversation unresolved. Only resolve a conversation if you have nothing to add.

  5. Do not use rebase to squash your commits or amend commits under review while the review is unresolved. If a review ends up with multiple rounds of reviews, squashing the commits makes it impossible for a reviewer to review just the changes made since the last review.

  6. Once you have completed the requested changes, assign the PR back the reviewer.

Note: All conversations should be resolved before a PR is merged.