PULL_REQUEST_TEMPLATE 3.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657
  1. <!--
  2. Thanks for sending a pull request! Here are some tips for you:
  3. 1. If this is your first time, please read our [contributor guidelines](https://github.com/elyra-ai/community/blob/main/contributing.md)
  4. 1.1 Please follow the [7 rules for a great commit message](https://github.com/elyra-ai/community/blob/main/contributing.md#creating-a-pull-request)
  5. 2. If the PR is unfinished, leave it as 'DRAFT', add '[WIP]' in your PR title, e.g., '[WIP] Your PR title ...' or use the 'status:Work in Progress' label.
  6. 3. Be sure to keep the PR description updated to reflect all changes.
  7. 4. Please write your PR title to summarize what this PR proposes.
  8. 5. If this PR involves UI changes, please provide a screen capture (before/after) for a faster review.
  9. 6. Remember to add 'Fixes #ISSUE_NUMBER' (or any [valid keyword](https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)) to the end of your message body to get the issue properly closed when the PR is merged.
  10. 7. Set the proper milestone based on the target release for the issue.
  11. 8. Consider whether any documentation need to be added or updated based on your changes.
  12. -->
  13. ### What changes were proposed in this pull request?
  14. <!--
  15. Please clarify what changes you are proposing. The purpose of this section is to outline the changes and how this PR fixes the issue.
  16. If possible, please consider writing useful notes for better and faster reviews in your PR. See the examples below.
  17. 1. If you refactor code that leads to class changes, showing the updated class hierarchy will help reviewers.
  18. 2. If there is design documentation, please add the link.
  19. -->
  20. ### How was this pull request tested?
  21. <!--
  22. If tests were added, say they were added here. Please make sure to add some test cases that check the changes thoroughly
  23. including negative and positive cases if possible.
  24. If it was tested in a way different from regular unit tests, please clarify how you tested step by step,
  25. ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future.
  26. If tests were not added, please describe why they were not added and/or why it was difficult to add.
  27. -->
  28. Developer's Certificate of Origin 1.1
  29. By making a contribution to this project, I certify that:
  30. (a) The contribution was created in whole or in part by me and I
  31. have the right to submit it under the Apache License 2.0; or
  32. (b) The contribution is based upon previous work that, to the best
  33. of my knowledge, is covered under an appropriate open source
  34. license and I have the right under that license to submit that
  35. work with modifications, whether created in whole or in part
  36. by me, under the same open source license (unless I am
  37. permitted to submit under a different license), as indicated
  38. in the file; or
  39. (c) The contribution was provided directly to me by some other
  40. person who certified (a), (b) or (c) and I have not modified
  41. it.
  42. (d) I understand and agree that this project and the contribution
  43. are public and that a record of the contribution (including all
  44. personal information I submit with it, including my sign-off) is
  45. maintained indefinitely and may be redistributed consistent with
  46. this project or the open source license(s) involved.