# Contributing to BlenderProc Thank you for your interest in BlenderProc. The following is a short set of guidelines for contributing to BlenderProc. These are guidelines, not rules. If you feel like this set can be improved, feel free to propose changes in a PR. ## Contents [Getting started](#getting-started) * [BlenderProc Source Code](#blenderproc-source-code) * [BlenderProc Design Decisions](#blenderproc-design-decisions) [Ways to contribute](#ways-to-contribute) * [Reporting bugs](#reporting-bugs) * [Suggesting enchancements](#suggesting-enchancements) * [Pull Requests](#pull-requests) [Styleguides](#styleguides) * [Git Commit Message and Branch Names](#git-commit-message-and-branch-names) * [Python Styleguide](#python-styleguide) * [BlenderProc Module Documentation Styleguide](#blenderproc-module-documentation-styleguide) * [BlenderProc Example Styleguide](#blenderproc-example-styleguide) ## Getting started ### BlenderProc Source Code BlenderProc is a small open source project: just one repository. So when you decide to contribute to our ongoing effort to improve this tool, it is expected that you are familiar with the [source code](blenderproc/) and made your way through the relevant [examples](examples/). ### BlenderProc Design Decisions At this point BlenderProc has a well-established project-wide code structure with key elements like modules, composite-modules, providers, utilities, examples, configuration files, etc. with the intent of keeping BlenderProc easy as an to use and easy to extend pipeline tool. The way the majority of this elements are developed is goverened by the [styleguides](#styleguides). But yes, it may happen such that the current way of organizing and developing is not suitable for your case, so use your best judgement. ## Ways to contribute ### Reporting bugs Bugs are tracked as [GitHub issues](https://guides.github.com/features/issues/). Create an issue, explain the problem and include additional details to help maintainers reproduce the problem: * Use a clear and descriptive title. * Describe the exact steps which reproduce the problem in as many details as possible. * Provide specific examples to demonstrate the steps: part of the config file, copy/pasteable code snippets, etc. * Explain which behavior you expected to see instead and why. * Include screenshots if possible. ### Suggesting enchancements Enhancement suggestions are tracked as [GitHub issues](https://guides.github.com/features/issues/). Create an issue and provide the following information: * Use a clear and descriptive title. * Provide specific examples to demonstrate the steps: part of the config file, copy/pasteable code snippets, etc. * Describe the current behavior and explain which behavior the enchancement will introduce. * Explain why this enhancement would be useful. ### Pull Requests In order to increase a pace of project-wide decision-making and maintain of the BlenderProc, please follow these steps to have your contribution considered by the maintainers: * Link to the issue that your change relates to. If there is not yet an issue for your bug or issue for an enchancement request, please open a new issue and then link to that issue in your pull request. * Fix description: short walk-through the concept of the solution. If it is a bug fix PR: * Verify that examples that use the fixed modules are working and their READMEs are updated if that is needed. If it is an enchancement/feature PR: * Provide a new example if major feature or enchancement is introduced. The contents of the PR (i.e. code, documentation, examples) must follow the [styleguides](#styleguides). While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted. ## Styleguides ### Git Commit Message and Branch Names Following is a simple pattern for Git Commit messages: ``` ():