Practices

Team agile practices

• 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)

Team development & testing practices

• DoD
• automated style checking
• testing: unit testing, integrated manual testing
• PR reviews
• branching (no straight pushes to master), issue = branch
• commit messages and issue referencing
• deployment:
  • test branch - is where the feature branches are getting merged into - deploys to the "test" plugin repo
  • master branch = test branch + all three OS level manual testing & bugs - deploys to the JB plugin repo ("stable")
• commenting the code

Pull requests and code review

Objectives:

• Improved quality of code.
• All the team members get involved in the reviewing process.
• We learn when we review.

Directives:

• 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.)

Further reading

• Google's code reviewing practices. An optional (but recommendable) read for reference.