This section is intended to cover how Matter uses GitHub Projects, Issues, Milestones, Releases, and Branches for program/project management in the code repository.
Matter uses issues as simple problem descriptions or feature requests. In general, all work contributed to the repository in the form of pull requests (PR) should be under the auspices of some open issue. This may seem onerous and in some cases duplicative, so consider these guidelines when deciding whether you can get away with not creating an issue:
Pull requests should be small and address a single, specific change to the code base. They should be easy to review, as a “yes, that's better”. Refrain from requesting review until all PR checks have completed successfully, lest you tire your reviewers.
In Matter parlance, a milestone is simply a tag for an expected due date or release. Milestones are intended to help contributors and their managers to prioritize work. There are 2 types: Date-based and Release-based.
Date-based milestones are named for their due date, typically a Friday of some week. Date-based milestones are normally assigned based on a guess about when something's likely to bubble up and get done based on current work load and resourcing. They are wishes, guesses.
Release-based milestones are named for the release version and may have flexible or subject-to-change due dates. Release-based milestones are intended to track release blockers.
A special “Not sure when” milestone is a marker for issues whose priority, scope, or blocking status have not been determined. Monthly review of these is a project goal.
Issues without milestones are those that have yet to be considered for one of the above. Weekly review of new issues is a project goal.
Projects are collections of issues, pull requests, and notes intended to capture larger efforts that don't fit in issues, have multiple-subsystems involved, or may span multiple milestones. We use projects 2 ways:
Issues can belong to any number of projects, but should generally only belong to one of the task-tracking projects (the first type).
Master should always be Matter's best branch. Release branches, once cut, are closed for any feature work. Software fixes for release branches must first land on master unless demonstrably infeasible.