Contributions

Contributions to pyVmomi's core are held to a higher standard than other projects in this project-family. Any request may be rejected for not following the standards. The projects pyvmomi-tools and pyvmomi-community-samples have much more lax commit rules and new developers are encouraged to commit there first before attempting to make changes to this much more conservative library. The pyvmomi-tools project incubates new features while pyvmomi-community-samples is focused on providing sample code for using the existing features in the library.

Commit Standards

1. Testing: All pull requests must provide unit tests to demonstrate the change. See: This Screencast on How To create a Unit Test. Ideally, your change, test, and fixture (VCRPY cassette) will all be encapsulated in a single commit to make things easy to review. Reviewer Note: In some cases, it will be appropriate to validate that the change was in fact necessary (you validate the change by restoring the code under test to it's earlier state and then running the test to observe that pyVmomi indeed fails before the change is made or merged.)

2. Obey formatting rules of the file you are editing. At the moment pyVmomi files may obey either the VMware formatting rules (3 spaces and UpCaseOnAllNames) or the standard pep8 rules. Follow the per-file established format carefully. Caveat: At some point in the future we will make a coordinated change to move all our code over to the pep8 standard. Unless your patch is specifically about those formatting changes and/or part of that coordinated effort, do not attempt to address formatting issues. Keeping classic VMware formatting helps us manage back-ports to pre-OpenSourced versions of the library.

3. All commits should be tied to an issue for tracking. This makes the construction of release notes easier and helps us give attribution to contributors at release time.