Building the drake community

[RussTedrake]

More contributors potentially means more features and better code (more bug fixes, etc); but we also need to maintain very high standards in terms of code quality and correctness. Opening this issue to discuss best practices for facilitating use by and contributions from the community. Here are a few thoughts from me:

• Need to provide a very stable and well-documented interface that external code can depend on. This will happen first in the C++ library interface that we are fleshing out now in preparation for a version 1.0.0 release.
• Need excellent documentation. see determine documentation standard for citing publications (from code comments) #1524
• Need contributors to be feel a sense of ownership / pride. Github gives credit for commits. Would like people to be able to cite their relevant research papers, etc. This can currently be accomplished via inline documentation and/or via the gallery
• Need better support for ROS workflow. e.g. add easier connectivity to ROS with e.g. a ROSCoordinateFrame #1185
• Need to minimize dependencies on expensive software packages / toolboxes.
• Need to continue support for mac, linux, and windows. Some features are still missing from windows (though I think it's exceptional how much we do support already; that was a lot of work).
• Need to provide simpler installation of precompiled distributions pip install drake #1183
• Aim to provide more support for additional higher-level prototyping languages (already have matlab, aim to support python, julia, ..., via swig Auto-generate Matlab bindings for our C++ libraries #1267, Demo of changes needed to wrap our C++ library in Python and matlab #1318)
• Better advertise the email list http://mailman.mit.edu/mailman/listinfo/drake-users
• Should we aim to give tutorials at ICRA/IROS? Is ROSCon a good model if it ever came to that?

Soliciting comments/feedback on the above (including relative prioritization) and any additional ideas.

[RussTedrake]

Recommendation: github has a convention for CONTRIBUTING.md (or txt, etc) which will put a small line at the top of a pull request page. "submit a pull request. see the code style guide. we presume that the contribution is made under the standard license..."

[RussTedrake]

recommendation: write c++ style guide using clang-format, or uncrustify. instruct contributors to run this file to format their files before commit. also editor plugins.

[RussTedrake]

other ideas:

• need to figure out the governance model and documenting it. (architecture governance board)
• build from source recommends people take a release tag, instead of master?

[mauricefallon]

• More information about the pull request review and test process would help: mentioning what Travis is, who will kick off the build servers, that a unit test is usually required with any new capability.
• Summarising notes of developers meetings on the wiki?
• Having a roadmap for future features.

Another developer conference to compare with is moos-dawg

[RussTedrake]

Recommendation: for industry support, compile to real-time OS (RT linux, vxworks, RTOS...)

[xuhao1]

For RT system, maybe RTAI is a good choice. One of my friend is developing RT-ROS based on this.
I recommend to have a Drake distribution on Docker.

[RussTedrake]

recommendation: clean up directory structure to capture "modules", as discussed in #1612 (comment)