Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Pull request checklist intent is unclear #1609
I've submitted a pull request and met with a checklist that I couldn't figure out who should fill and use and how:
What the red "no_entry_sign" means? Is it bad if checked or bad if unchecked?
I can see how "makes breaking changes" or "design changes" are red flags that developers should self-declare (although this can be checked very easily by the reviewers, too). So, checked means something bad (or at least requires attention).
"Breaking change" is also very vague. Is fixing a bug a breaking change? (if an application relied on the earlier, incorrect behavior, would you consider it a breaking change?)
"Adds the License notice to new files" this time , checked means OK
"Adds Python wrapping" - I don't understand this at all. I would expect that Python wrapping is automatic and transparent. Maybe you mean changed API? Or that Python wrapping has to be tested?
"Adds tests and baseline comparison (quantitative)." and "Adds test data." are so tightly linked that it should be one item.
It would also make the checklist more clear if the items were simple past tense.
Something like this would be more clear:
The PR could be merged if all items are checked.
"Python wrapping is added for any new classes" - yes, this is clear, we just need to add a link to the documentation that describes how to do this.
I also share that feeling to a certain extent and admit that the checkbox list may be subject to interpretation: it may be used differently by contributors, and thus may not be used or be useful at all in that case.
The idea of using checkboxes was, among others, to allow reviewers spot more easily and especially PRs that may imply changes that may impact the toolkit to an extent which needs special attention. It is not exclusive of ITK.
I admit that even in the best case, since they depend on a human checking them, at times they may not honor the changes of the PR.
Since I am under a heavy workload now, I would allow myself some more time, meaning at least a month, to think about them and propose a change. Otherwise, if you reach consensus faster, please, feel free to move forward and merge.
Thanks! Updated version: