Contributions are welcomed via pull requests on GitHub. Contact the HOOMD-blue developers before starting work to ensure it meshes well with the planned development direction and standards set for the project.
New features should be applicable to a variety of use-cases. The HOOMD-blue developers can assist you in designing flexible interfaces.
Expensive code paths should only execute when requested.
Write, test, and optimize your GPU kernels on the latest generation of GPUs.
Bug fixes should be based on maint. New features should be based on master.
All changes in a pull request should be closely related. Multiple change sets that are loosely coupled should be proposed in separate pull requests.
All contributors must agree to the Contributor Agreement (ContributorAgreement.md) before their pull request can be merged.
SourceConventions.md defines the style guidelines for HOOMD-blue code.
Use doxygen header comments for classes, functions, etc. Also comment complex sections of code so that other developers can understand them.
Your changes should compile without warnings.
Add unit tests for all new functionality.
The developer should run research-scale simulations using the new functionality and ensure that it behaves as intended.
Document public-facing API with Python docstrings in Google style.
Add demonstrations of new functionality to hoomd-examples.
Each user-facing Python class, method, etc. with a docstring should have versionadded, versionchanged, and deprecated Sphinx directives so that users will be aware of how functionality changes from version to version.
Update the credits documentation to reference what each developer contributed to the code.
Propose a short concise entry describing the change in the pull request description.