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](https://openvmm.zulipchat.com/) 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.
