11## CHIP Project Flow
22
3- This section is intended to cover how CHIP uses GitHub Projects,
4- Issues, Milestones, Releases, and Branches for program/project
5- management in the code repository.
3+ This section is intended to cover how CHIP uses GitHub Projects, Issues,
4+ Milestones, Releases, and Branches for program/project management in the code
5+ repository.
66
77### Issues
88
9- CHIP uses issues as simple problem descriptions or feature requests. In
10- general, all work contributed to the repository in the form of pull requests
11- (PR) should be under the auspices of some open issue. This may seem onerous and
12- in some cases duplicative, so consider these guidelines when deciding whether to
13- you can get away with not creating an issue:
14-
15- * Trivial fixes: issues can function as TODO lists, simple reminders that
16- something should be addressed. Sometimes, though, the work required to
17- fix is smaller than the work required to write the issue.
18- * Issues intended to be addressed by a PR may not actually be fixed or
19- may regress.
20- * Issues can span PRs (as PRs should be as small as possible, but no smaller).
21- * Issues help form an important basis for release notes. Any PR that addresses
22- a problem that should have release visibility, please do open an issue.
9+ CHIP uses issues as simple problem descriptions or feature requests. In general,
10+ all work contributed to the repository in the form of pull requests (PR) should
11+ be under the auspices of some open issue. This may seem onerous and in some
12+ cases duplicative, so consider these guidelines when deciding whether to you can
13+ get away with not creating an issue:
14+
15+ - Trivial fixes: issues can function as TODO lists, simple reminders that
16+ something should be addressed. Sometimes, though, the work required to fix is
17+ smaller than the work required to write the issue.
18+ - Issues intended to be addressed by a PR may not actually be fixed or may
19+ regress.
20+ - Issues can span PRs (as PRs should be as small as possible, but no smaller).
21+ - Issues help form an important basis for release notes. Any PR that addresses a
22+ problem that should have release visibility, please do open an issue.
2323
2424### Pull requests
2525
2626Pull requests should be small and address a single, specific change to the code
27- base. They should be easy to review, as a "yes, that's better". Refrain from
27+ base. They should be easy to review, as a "yes, that's better". Refrain from
2828requesting review until all PR checks have completed successfully, lest you tire
2929your reviewers.
3030
3131PR Don'ts:
32- * Don't combine unrelated changes. E.g. if the PR addresses a bug in some
33- C code, an update to the top-level .gitignore doesn't belong.
34- * Don't make stacks. E.g. if a change in a component requires a new feature
35- or even a small tweak in one or more of its dependencies, each dependency
36- change belongs in its own separate PR.
3732
33+ - Don't combine unrelated changes. E.g. if the PR addresses a bug in some C
34+ code, an update to the top-level .gitignore doesn't belong.
35+ - Don't make stacks. E.g. if a change in a component requires a new feature or
36+ even a small tweak in one or more of its dependencies, each dependency change
37+ belongs in its own separate PR.
3838
3939### Milestones
4040
4141In CHIP parlance, a milestone is simply an expected due date or release.
4242
43- Date-based milestones start with an "M" and have the form M3, M3.2, M4,
44- etc. corresponding to the number of months since January 1, 2020, and generally
45- mean the last Friday of that month. E.g. M1 corresponds to EOB January 24,
46- 2020 . The Morrow milestone is a special milestone that means "unprioritized" or
47- "unscheduled" or "unscoped".
43+ Date-based milestones start with an "M" and have the form M3, M3.2, M4, etc.
44+ corresponding to the number of months since January 1, 2020, and generally mean
45+ the last Friday of that month. E.g. M1 corresponds to EOB January 24,
46+
47+ 2020 . The Morrow milestone is a special milestone that means "unprioritized" or
48+ "unscheduled" or "unscoped".
4849
4950The form of the names of release-based milestone names are TBD, and may have
5051flexible or changing dates.
@@ -53,20 +54,20 @@ flexible or changing dates.
5354
5455Projects are collections of issues, pull requests, and notes intended to capture
5556larger efforts that don't fit in issues, have multiple-subsystems involved, or
56- may span multiple milestones. We use projects 2 ways:
57+ may span multiple milestones. We use projects 2 ways:
5758
58- 1 . To track burn down on a larger task. When constructing such a project, it's
59- important to think in terms of something that will eventually have
60- an end, i.e. a definite scope.
59+ 1 . To track burn down on a larger task. When constructing such a project, it's
60+ important to think in terms of something that will eventually have an end,
61+ i.e. a definite scope.
61622 . To categorize issues, denote broader efforts without a definite time scope.
62- These projects might reflect or show burndown or percent complete, but are mostly
63- used to view where effort is going.
63+ These projects might reflect or show burndown or percent complete, but are
64+ mostly used to view where effort is going.
6465
6566Issues can belong to any number of projects, but should generally only belong to
6667one of the task-tracking projects (the first type).
6768
6869### Branches, releases, and general development flow
6970
70- Master should always be CHIPs best branch. Release branches, once cut, are
71- closed for any feature work. Software fixes for release branches must first
72- land on master unless demonstrably infeasible.
71+ Master should always be CHIPs best branch. Release branches, once cut, are
72+ closed for any feature work. Software fixes for release branches must first land
73+ on master unless demonstrably infeasible.
0 commit comments