Include guidance on adding new operators in Contributing.md #1416
Conversation
Often times new PR descriptions are light on details necessary for implementors to understand the motivation behind their addition and to correctly implement them.
prasanthpul
requested review from
linkerzhang,
bddppq,
ankkhedia and
spandantiwari
|
|
||
| For implementors in the ONNX community to be able to effectively implement any new operators proposed, pull requests should include: | ||
|
|
||
| - Operator description - just 1 to 2 sentences describing the operation (e.g. “The new Expand operator broadcasts an input tensor to an output shape using a shape tensor”). A more complete description will be found in the actual PR, but readers should be able to get a summary up front without reading through the diff. |
There was a problem hiding this comment.
1 to 2 sentences sounds inappropriate... A clear definition is wanted. I think we should add the steps to generate/update Operators.md and TestCoverage.md.
There was a problem hiding this comment.
@houseroad Yes, the description in Operators.md had better be clearly defined. I was referring to the opening comment in the PR, for which people could be a little more brief than what they say in Operators.md, but not so brief as PR 1089 "This PR will add a new operator "expand" to onnx", as it becomes tedious to dig into the raw files across dozens of PR's when trying to get a holistic view of what new operators we need to support during new releases. Maybe people should just copy the description from their Operators.md into the first PR comment? Regarding regenerating Operators.md and TestCoverage.md, I'd support someone adding those details who is familiar with the process (as I don't know them).
There was a problem hiding this comment.
e.g. "Operator description - a clear description of what the operator does and how it works, both in Operators.md and the opening PR comment, so that readers can understand a summary even before reviewing the files changed (you can just copy the summary from Operators.md into the PR comment)."
There was a problem hiding this comment.
@fdwr I agree with your intent of having a smaller description in the opening comment of the PR and full detailed description in Operators.md doc. I think we just need to spell that out in the section above more clearly.
Often times new PR descriptions are light on details necessary for implementors to understand the motivation behind their addition and to correctly implement them.
Often times new PR descriptions are light on details necessary for implementors to understand the motivation behind their addition and to correctly implement them.
Often times new PR descriptions are light on details necessary for implementors to understand the motivation behind their addition and to correctly implement them.