mirror of
https://github.com/status-im/pluto.git
synced 2026-08-31 12:31:08 +00:00
73 lines
2.7 KiB
Markdown
73 lines
2.7 KiB
Markdown
Development is split in feature driven milestones. Each milestone's goal is to ship an identified set of features in a short (few weeks) time.
|
|
|
|
High level scope of a milestone is agreed on by the whole team. Developers then create a set of atomic and detailed github issues. Based on those an estimated delivery date is defined.
|
|
Reasonable efforts are made to not modify the scope of a milestone once started.
|
|
|
|
Issues are closed regularly to get good sense of progress.
|
|
If finished early, development proceed to next milestone.
|
|
|
|
# Workflow
|
|
|
|
Once an issue assigned, a developer work on implementing and once ready pushes a PR. It's then its responsibility to make sure this PR gets merged quick. PRs are the only way to introduce new code in the codebase.
|
|
A [trunk based development](https://paulhammant.com/2013/04/05/what-is-trunk-based-development/) model is followed. A PR is reviewed with great care: ultimate goal is zero regression and master is considered production quality.
|
|
|
|
## Pull request content
|
|
|
|
A pull request is linked to an issue. Sufficient information is provided so that the review process is simplified.
|
|
|
|
How to link PR and issues:
|
|
|
|
* commit name: [#XXX] sldfjdsfj
|
|
* PR title is the same as commit name
|
|
* PR comment starts with `fixes #123` for easier issue navigation
|
|
|
|
## Definition of done
|
|
|
|
To be considered ready for review, a pull request must (when relevant):
|
|
|
|
* not define TODOs
|
|
* have a reasonable design (no hack policy)
|
|
* be pixel perfect
|
|
* have automated tests
|
|
* have commented code
|
|
* provide documentation
|
|
* have been demoed
|
|
|
|
Developers must go the extra mile to perform manual tests.
|
|
|
|
## Pull request lifecycle
|
|
|
|
Once pushed a pull request will go through a review cycle. Whenever possible checks are automated, e.g.
|
|
|
|
* compilation / unit tests execution via CircleCI
|
|
* code quality
|
|
* patterns usage
|
|
|
|
Once checks pass, the pull request must be reviewed.
|
|
Reviewers are assigned automatically, based on defined [codeowners](https://help.github.com/articles/about-codeowners/)
|
|
|
|
A reviewer might request changes. If agreement emerges an individual commit is created to simplify follow up reviews.
|
|
All commits are squashed into a single commit for final merge.
|
|
|
|
# Tooling
|
|
|
|
Github tools are leveraged: issues, pull requests and milestones.
|
|
|
|
A github project helps tracking overall progress. Kanban is roughly followed.
|
|
|
|
## Tags
|
|
|
|
Tags are used to identify and track progress of issues and pull requests.
|
|
|
|
Initial tags are first added by issue creator. Those can be completed by the whole team.
|
|
|
|
### Issues tags
|
|
|
|
* type: bug, enhancement, maintenance, question
|
|
* priority: critical, high, medium, low
|
|
* status: abandoned, duplicate, wontfix, on hold
|
|
|
|
### PR tags
|
|
|
|
* status: available, in progress, blocked by design, 3rd party, review needed, revision needed, accepted
|