-
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 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).
We develop our code test driven as far as possible. Work happens in branches and gets reviewed by a minimum of 1 other person that has to approve your changes. Except for some infra stuff, nothing gets pushed directly to main.
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.
As mentioned above, @0815Sailsman or @flamion are responsible for writing new stories and populating the backlog. If there is not enough work, please contact one or both of them (ideally through a role ping in the discord).
If you find a bug, feel free to open a bug ticket yourself, there is a template which you can just use (you will get asked which template to use when creating a new issue).
All changes should be submitted through pull requests. One or more reviewers should be assigned and ideally notified through discord that you've assigned them and are awaiting review. The story you are working on should be moved to Awaiting Review on the board.
Stories should be linked to the pull requests so that they get closed automatically once the PR is merged. In any case, the person working on the story should check if the story was correctly closed once the PR has been merged.
The reviewers should carefully review the changes, ensuring that the story is implemented correctly and that the code is well tested. They should not approve a pull request until all issues raised have been resolved. Once they are sufficiently satisfied, they should approve the pull request and ideally notify the person awaiting review that they're finished their review and approved it. If they request changes, the person should ideally also be notified.
After approval has been given, the person who opened the pull request is the one who merges the changes. The reviewer should not merge for them.
Comments should be needed sparingly, the code itself should be clear enough. If you write comments, they should especially contain why something happens and not how, as that is visible by reading the code, the why is not always as obvious. That doesn't mean you should never write any comments of how things are done / what the code is doing, just that those should be reserved for especially complex pieces of code. Always write the code and comments to aid people unfamiliar with those parts of the codebase in understanding what is happening and why so that they can easily and safely make changes if needed.