By participating in this project, you agree to abide by the [CODE OF CONDUCT](./CODE_OF_CONDUCT.md).

OpenVMM uses the “fork-and-pull” development model. See [GitHub forks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks) for more information on forks. Please follow these steps to merge your changes to OpenVMM:
1. [Fork and clone](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo#forking-a-repository) the OpenVMM repo.
2. Create a branch for your changes, develop your code and push your changes.
3. Create a PR against the main branch of the OpenVMM repository [from your fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).
4. Go through the PR review process. 

Following our [coding conventions](.\guide\src\dev_guide\contrib\code.md) and writing a descriptive commit message will increase the chance that a PR is accepted.

We strongly suggest asking for feedback before starting to work on a new feature, functionality, etc. so that we can provide feedback and discuss how we can collaborate on this and support contributors. 

To engage with project maintainers, contributors can reach out on Zulip (link coming soon) and then start drafting a [GitHub issue](https://github.com/microsoft/openvmm/issues/new?template=Blank+issue) after getting some preliminary feedback on Zulip, or they can open a GitHub issue to get preliminary feedback on GitHub and then reach out to us on Zulip to get some more synchronous support. 

We normally use Zulip for more informal conversations and GitHub Issues for more formal, auditable, public discussion and progress tracking. We encourage contributors to use both in either order based on preference.