Suggestions for contributing to Documentation

Question

Big fan of this project and hoping to contribute to the documentation. This is something I would like to do quite a bit of over the course of the next year or two. Wondering if someone might suggest how this could be most useful to the team. I am inclined to start by contributing minimal examples to the Python tutorials. First off the top of my head would be "Loading a URDF and generating symbolic equations of motion". Many of these things are covered in Russ' Deepnote examples for under-actuated, but it makes sense to me to have a lot of minimal examples with simple titles and good organization.

Questions:

1. Do these need to work in Deepnote/CoLab/Jupyter/stand-alone-IDE?
2. Does anyone have a "top 10" things that need documentation
3. Would it be best to make many individual pull requests with individual tutorials?

If this is not helpful, I'm happy to keep it in a public repo on my own account and leave the core team alone. From experience though, I've found that the one thing people actually want help on is documentation because they have better things to do.

Open to any comments or suggestions.

Best, Drew

• Bergi: I’m voting to close this question because it belongs on the project's mailing list, discussion forum, or issue tracker. It's off-topic on Stack Overflow.
• Bergi: It seems the answers you are looking for can be found at github.com/RobotLocomotion/drake/blob/master/CONTRIBUTING.md or drake.mit.edu/developers.html

Answer 1

Drake actively welcomes contributions. The more the community takes ownership the better. And pushing changes upstream to Drake makes it easier for everyone to benefit from your contributions.

I'd strongly recommend a series of small PRs for small tutorials. As you begin submitting PRs, reviewers will help you get them over the finish line and if there are undocumented steps for contributing tutorials, it'll give us a chance to upgrade that contribution documentation.

There might be questions about individual tutorials and there might be churn in terms of how they get organized, but I believe that there's nothing better than a live PR to get the conversation flowing.

Dive in and we'll see what we can do to make it as smooth as possible.

• Drew Hamilton: Great. I appreciate the quick response, Sean. Expect to see a few pull requests soon, and I welcome any feedback. If you see my PR, feel free to give me a hard time about code structure, best practices etc. That will help me as much as anyone using these as a reference,