[B32] Lack of proper pull request and CI workflows

[juliankuners]

Development on Mithril happens for the most part directly on the Mithril default branch, namely the dev branch. In addition, Mithril's CI consists solely of building the Mithril Go project. Considering the complexity of the Mithril project and that Mithril is developed by a team in an open-source repository, this increases the risk of introducing bugs in the project. In addition, the lack of pull requests that group related commits together as part of a collective pull request makes tracing changes and their reasoning harder. Finally, code review of commits is not possible if the commits are pushed directly to the default branch instead of being introduced as a pull request.

Recommendation

To increase code quality, reduce the risk of introducing bugs, and introduce more documentation about codebase changes, we recommend to disable the ability to push changes directly to the default branch. Instead, changes should only be possible by opening a pull request containing the requested changes and merging that pull request into the default branch. In addition, we advise to use the code review functionality of pull requests as well as making the code review process mandatory by requiring at least one approval from another maintainer on a pull request before merging. Further, pull requests should contain details about the changes and their motivation, possibly referencing other materials or issues.

We also recommend to introduce more CI workflows that run all available unit and integration tests of the code base. A pull request should only be allowed to be merged once all workflows successfully pass. In the ideal case, bugs and new features introduce respective regression tests to make sure that intended functionality or fixes do not regress due to other later codebase changes.