-
Notifications
You must be signed in to change notification settings - Fork 0
Team Decisions
description
We decided in the team to roughly follow the extreme programming workflow.
@0815Sailsman (and in part @flamion) will mostly take over the role of PM and be responsible for populating the backlog with new issues. Once the team decides, that the todo column of our kanban board is too empty, we will have an IPM and as a team decide which stories from the backlog will be moved to the todo column. In the scope of this meeting, we will also discuss all of these moved tickets and answer any emerging questions regarding them. This ensures, that we always have enough work available as a team.
We as a team decided to put a lot of focus on testing our application. Especially the Bytecode VM should be tested extensively. If it fits your situation, try to apply TDD. In general, try to unit test more complex logic sections, by themselves, integration test stuff like endpoints, and e2e test larger workflows (e.g. an entire game walkthrough).
When it comes to our git workflow, we try to be relatively flexible. Your as a developer are responsible for deciding, if your current ticket / story / preference requires you to work on a branch inspired by gitflow or not. If you feel confident enough to adopt trunk based development feel free to do that aswell.
We want to work with a hexagonal / clean architecture in the backend.
Every developer is responsible by themselves for writing javadoc / doc comments in general for their methods and docs in general. Please be thorough with writing docs!
As a team we decided that we have a few rules to keep the git history clean and easily navigable and also ensure code quality.
Our commit messages should adhere to the following format [#123] Make xyz do wombo or [#123, #456] Make foo do the bar.
That means, first the issue(s)/stories worked on in the commit get referenced in square brackets.
The commit message itself should be written in passive form i.e. "Address feedback" or "Rename parser package to compiler", as if you are telling git what to do to create the changes contained in the commit.
For minor changes that do not have a linked story, you can use [#0]. If the change is a bit larger than just minor, just ask @0815Sailsman or @flamion on how to proceed. Either a story will be created for the change or you'll get told to just use [#0]
Commits should be atomic, i.e. contain only related changes. If you do a "drive by fix", put it in a separate commit. Don't put two unrelated changes in a single commit. This is useful for keeping track of what happened, finding bugs via git-bisect or simply reverting just a single change.
No unformatted code should be committed, run the linters and formatters prior to committing.
Incorrectly formatted code and/or code that does not pass the linter will not be accepted in pull requests, this is also enforced through automated actions.
Our lovely infra team has crafted a handful of pre-commit hooks which everyone should install. They ensure on your side that unfit commits don't even get created instead of getting rejected later through the automated PR checks. They exist to aid you.