1# Development Process
2
3We use [issues] for asking questions ([open one here][newissue]!) and tracking
4bugs and unimplemented features, and [pull requests] (PRs) for tracking and
5reviewing code submissions. We triage new issues at each of our bi-weekly
6[Wasmtime meetings][meetings].
7
8### Before submitting a PR
9
10Consider opening an issue to talk about it. PRs without corresponding issues
11are appropriate for fairly narrow technical matters, not for fixes to
12user-facing bugs or for feature implementations, especially when those features
13might have multiple implementation strategies that usefully could be
14discussed. Changes that will significantly affect stakeholders should first be
15proposed in an [RFC](./contributing-rfc-process.md).
16
17Our issue templates might help you through the process.
18
19### When submitting PRs
20
21 - Please answer the questions in the pull request template. They are the
22   minimum information we need to know in order to understand your changes.
23
24 - Write clear commit messages that start with a one-line summary of the
25   change (and if it's difficult to summarize in one line, consider
26   splitting the change into multiple PRs), optionally followed by
27   additional context. Good things to mention include which areas of the
28   code are affected, which features are affected, and anything that
29   reviewers might want to pay special attention to.
30
31 - If there is code which needs explanation, prefer to put the explanation in a
32   comment in the code, or in documentation, rather than in the commit message.
33   Commit messages should explain why the new version is better than the old.
34
35 - Please include new test cases that cover your changes, if you can. If you're
36   not sure how to do that, we'll help you during our review process.
37
38 - For pull requests that fix existing issues, use [issue keywords]. Note that
39   not all pull requests need to have accompanying issues.
40
41 - When updating your pull request, please make sure to re-request review if
42   the request has been cancelled.
43
44### Focused commits or squashing
45
46We are not picky about how your git commits are structured. When we merge your
47PR, we will squash all of your commits into one, so it's okay if you add fixes
48in new commits.
49
50We appreciate it if you can organize your work into separate commits which each
51make one focused change, because then we can more easily understand your
52changes during review. But we don't require this.
53
54Once someone has reviewed your PR, it's easier for us if you _don't_ rebase it
55when making further changes. Instead, at that point we prefer that you make new
56commits on top of the already-reviewed work.
57
58That said rebasing (or merging from `main`) may still be required in situations
59such as:
60
61* Your PR has a merge conflict with the `main` branch.
62* CI on your PR is failing for unrelated reasons and a fix was applied to `main`
63  which needs to be picked up on your branch.
64* Other miscellaneous technical reasons may cause us to ask for a rebase.
65
66If you need help rebasing or merging, please ask!
67
68### Review and merge
69
70Anyone may submit a pull request, and anyone may comment on or review others'
71pull requests. However, one review from somebody in the [Core Team] is required
72before the Core Team merges it.
73
74Even Core Team members must create PRs and get review from another Core Team
75member for every change, including minor work items such as version bumps,
76removing warnings, etc.
77
78[issues]: https://guides.github.com/features/issues/
79[pull requests]: https://help.github.com/articles/about-pull-requests/
80[issue keywords]: https://help.github.com/articles/closing-issues-using-keywords/
81[Core Team]: https://github.com/orgs/bytecodealliance/people/
82[newissue]: https://github.com/bytecodealliance/wasmtime/issues/new
83[meetings]: https://github.com/bytecodealliance/meetings/tree/main/wasmtime
84