Development methodology

@how You will notice from my latest contributions, that I am not anymore aspiring to write separate issues for each concern I am addressing. I see the git-flow you showed with committing directly to master as a chance of simplification for the two major branches that we maintain:

  • develop receives a flow of well documented commits and is coordinated with eventual feature branches, leading to merge requests.
    Extra branches will be used for extended features.
  • master receives merges and hotfixes by @how, and remains the basis for rebasing develop onto, securing a clean merge of contributions.

This means we reduce the overhead of preliminary documentation neccessary to get to a suitable implementation. As long as merge requests and commits are completely explained, the git log itself tells the story of what happens.

Issues will remain neccessary for more complicated and long-term oriented developments.

Here we learned to separate between two perspectives:

  • an Issues board that carries short-lived (developer) concerns which need to be addressed quickly, and
  • a Development board which carries long-term oriented, epic (user) stories.

Additionally we prefer to communicate in written text in GitLab, IRC/Riot, or here, to continually build up a transparent process.

Human meetings remain neccessary when we have to converse around subjects outside of the technical domain of this work.

1 Like