-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update design docs instructions #4183
base: rolling
Are you sure you want to change the base?
Conversation
Signed-off-by: GitHub <[email protected]>
Signed-off-by: GitHub <[email protected]>
Design docs are a way to document repository or package specific design decisions. | ||
This is different than `ROS Enhancement Proposals (or REPs) <https://ros.org/reps/rep-0000.html>`__, which are for larger decisions that often effect the ROS community. | ||
If you are unsure if you should do a design document or a REP, you can ask the ROS 2 team. | ||
A good place to ask is in the weekly ROS 2 meeting, or in a Github issue in a relevant ROS 2 repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A good place to ask is in the weekly ROS 2 meeting, or in a Github issue in a relevant ROS 2 repository. | |
A good place to ask is to open a GitHub issue in a relevant ROS 2 repository. |
Design docs should be placed in a ``doc`` directory in the relevant repository or package. | ||
And submitted as a pull request that references any related Github issues. | ||
Make sure to mention any additional context in the pull request such as if the design doc is intended for a specific ROS version. | ||
Feedback for the design doc wil be made directly on the pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design docs should be placed in a ``doc`` directory in the relevant repository or package. | |
And submitted as a pull request that references any related Github issues. | |
Make sure to mention any additional context in the pull request such as if the design doc is intended for a specific ROS version. | |
Feedback for the design doc wil be made directly on the pull request. | |
Design docs should be placed in a ``doc`` directory in the relevant repository or package. | |
Make sure to mention any additional context in the pull request such as if the design doc is intended for a specific ROS version. | |
Feedback for the design doc will be made directly on the pull request. |
.. note:: | ||
Design docs should never include confidential information and they are not required for bug fixes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.. note:: | |
Design docs should never include confidential information and they are not required for bug fixes. | |
.. note:: | |
Design docs should never include confidential information and they are not required for bug fixes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm with @clalancette suggestions.
@audrow Friendly ping here. |
I tried to make the relevant changes to suggest using a
doc
directory and to remove information about our old design docs process.