Added a template for PRs#4313
Conversation
| @@ -0,0 +1,30 @@ | |||
| ## PR Description: *short_description* | |||
There was a problem hiding this comment.
Doesn't it just duplicate the PR title?
| ## PR Description: *short_description* | ||
|
|
||
| ### Tickets: | ||
| - *ticket-id* |
There was a problem hiding this comment.
Can we add tickets from private bug tracer here?
There was a problem hiding this comment.
I think we can add the bug id
| - [ ] I agree to contribute to the project under Apache 2 License. | ||
| - [ ] To the best of my knowledge, the proposed patch is not based on a code under GPL or other license that is incompatible with OpenVINO | ||
| - [ ] The PR is proposed to proper branch | ||
| - [ ] There is reference to original bug report and related work |
There was a problem hiding this comment.
What if it is a new feature?
There was a problem hiding this comment.
bug / feature can be selected via labels.
And sometimes it's hard to say - it's bug or feature :)
There was a problem hiding this comment.
I updated the message
| - [ ] Unit tests | ||
| - [ ] Function tests | ||
| - [ ] e2e tests | ||
| - [ ] Component dependent tests |
There was a problem hiding this comment.
IMHO, not needed, since CI is launched automatically.
There was a problem hiding this comment.
In this sentence I mean that contributor should think about tests which are needed for his PR.
| - [ ] User guide update | ||
| - [ ] Developer guide update | ||
| - [ ] Specification update | ||
| - [ ] Component specific guides |
There was a problem hiding this comment.
IMHO, if the PR relates to the Documentation it will be mentioned in its Title/Details section. I don't see the reason to duplicate this information in the Checklist.
There was a problem hiding this comment.
If you add a new functionality you need to add a documentation for it. In this checklist contributor can think about different documentations and update if it is required.
There was a problem hiding this comment.
For me the checklist looks like obligatory conditions. But developer don't need to update User guide if the PR modifies internal things.
|
The purpose of PR description is to help reviewers to understand which problem it solves and what are the peculiarities of the solution. So as a reviewer I don't expect in PR to see some "checkboxes" that reminds developer not to forget to do something. All this rules that developer must follow must be located inside developer guide but bot in PR. So instead of searching for particular checkboxes I insist to work on our guidelines and make them clean and transparent for any developers so they can always rely on them and follow them but not checkboxes in PR that doesn't cover all aspects. So from my point of view the guidelines is the right way how we can grow our opensource/contribution culture. The problem that developers do not put any description to PR or miss some parts (like tests, documentation, code-style etc.) can be solved if reviewers will point contributors to specific parts in contribution guideline or component specific guides which needs to be explained or implemented. And if all reviewers will follow this approach and put dev-guides in the center of development flow then in future all contributors will rely on them by default and the quality of PRs will increase. Let's look at the changes you propose:
Check-list section:
So from my point of view only "Description" and "Tickets" sections make sense. |
|
Thank you guys, I got feedback from you. I will update the PR and notify you. |
|
I updated the template |
Details:
Tickets: