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.
6
7### Before submitting a PR
8
9Consider opening an issue to talk about it. PRs without corresponding issues
10are appropriate for fairly narrow technical matters, not for fixes to
11user-facing bugs or for feature implementations, especially when those features
12might have multiple implementation strategies that usefully could be discussed.
13
14Our issue templates might help you through the process.
15
16### When submitting PRs
17
18 - Please fill in the pull request template as appropriate. It is usually
19   helpful, it speeds up the review process and helps understanding the changes
20   brought by the PR.
21
22 - Write clear commit messages that start with a one-line summary of the
23   change (and if it's difficult to summarize in one line, consider
24   splitting the change into multiple PRs), optionally followed by
25   additional context. Good things to mention include which areas of the
26   code are affected, which features are affected, and anything that
27   reviewers might want to pay special attention to.
28
29 - If there is code which needs explanation, prefer to put the explanation in
30   a comment in the code, or in documentation, rather than in the commit
31   message.
32
33 - For pull requests that fix existing issues, use [issue keywords]. Note that
34   not all pull requests need to have accompanying issues.
35
36 - Assign the review to somebody from the [Core Team], either using suggestions
37   in the list proposed by Github, or somebody else if you have a specific
38   person in mind.
39
40 - When updating your pull request, please make sure to re-request review if
41   the request has been cancelled.
42
43### Focused commits or squashing
44
45We generally squash sequences of incremental-development commits together into
46logical commits (though keeping logical commits focused). Developers may do
47this themselves before submitting a PR or during the PR process, or Core Team
48members may do it when merging a PR. Ideally, the continuous-integration tests
49should pass at each logical commit.
50
51### Review and merge
52
53Anyone may submit a pull request, and anyone may comment on or review others'
54pull requests. However, one review from somebody in the [Core Team] is required
55before the Core Team merges it.
56
57Even Core Team members should create PRs for every change, including minor work
58items (version bump, removing warnings, etc.): this is helpful to keep track of
59what has happened on the repository. Very minor changes may be merged without a
60review, although it is always preferred to have one.
61
62[issues]: https://guides.github.com/features/issues/
63[pull requests]: https://help.github.com/articles/about-pull-requests/
64[issue keywords]: https://help.github.com/articles/closing-issues-using-keywords/
65[Core Team]: https://github.com/orgs/bytecodealliance/people/
66[newissue]: https://github.com/bytecodealliance/wasmtime/issues/new
67