-
Notifications
You must be signed in to change notification settings - Fork 6
Practices
nikke234 edited this page Mar 1, 2021
·
15 revisions
- daily time is 13:00
- daily space (on-site: A146 & remote in slack if any member is away)
- weekly time is on Wednesdays at 12:00
- Sprint duration (3 weeks)
- other ceremonies (demo/retro/planning)
- QA (testing)
- DoD
- automated style checking
- testing: unit testing, integrated manual testing
- PR reviews
- branching (no straight pushes to master), issue = branch = a PR (eventually)
- commit messages and issue referencing
- deployment:
- add a GitHub release tag (on master branch) to deploy the plugin
- if you mark the release as a pre-release, then it will deploy to the test channel, but this isn't used at the moment
- commenting the code
- Improved quality of code.
- All the team members get involved in the reviewing process.
- We learn when we review.
- The creator of a PR requests two reviewers of their choice (e.g. you can choose one who you think knows that part of code very well and one who perhaps not)
- The requested people either do the review, or (if they are too busy with other things or have some other valid reason) just leave a short comment-only review explaining their situation and request someone else instead.
- Anyone can add additional reviewers to a PR, if they feel the code in question should be looked by more than two people (or by some specific person).
- The PR should be approved by at least two of its reviewers. On top of that, if more than two people are marked as reviewers, all of them should have left either approval or comment-only review. In other words: if there are disapproving reviews or some assigned reviewers haven't left a review yet, the PR shouldn't be merged. (If there's a valid reason, an extra reviewer who hasn't left a review can be unassigned, though.)
- Google's code reviewing practices. An optional (but recommendable) read for reference.
- the list lives here
- the list lives here