From f058eebeaabe9f71294ac539c32c83e232a33f6e Mon Sep 17 00:00:00 2001 From: Hugo Gruson <10783929+Bisaloo@users.noreply.github.com> Date: Thu, 15 Feb 2024 11:24:20 +0100 Subject: [PATCH 1/2] Add agile figure from Melissa Fix #48 --- principles.qmd | 2 ++ 1 file changed, 2 insertions(+) diff --git a/principles.qmd b/principles.qmd index bfaaecd..6351603 100644 --- a/principles.qmd +++ b/principles.qmd @@ -49,6 +49,8 @@ The main objective of our collaboration framework will be to optimize interactio To maximize agility, we recommend also adopting the lean principle in which the amount of work in progress (WIP) at any time is minimized. In other words, it is more efficient to work on a few MVPs and deliver value quickly, rather than working on many MVPs at the same time, resulting in a lot of WIP and low completion rates. We recommend using Kanban boards to keep track of progress, and as a tool for identifying long-lasting WIP, likely indicative of blockage or issues which need addressing. These boards should be fully public to encourage and facilitate external visibility and contributions. +![The Epiverse-TRACE agile workflow for new projects, as recorded by [Melissa Avila](https://massabiosjuntos.com/melissadibuja/) during the Epiverse-TRACE Summit 2023 in Bogotá, CC BY.](figures/agile.png){fig-alt="The Epiverse-TRACE agile strategy is graphically represented as a workflow composed of 7 steps connected by arrows. The steps are: 1. Pitch the idea; 2. Seek feedback; 3. Create the design document; 4. Seek feedback; 5. Create repository from packagetemplate; 6. Start initial development; 7. Seek feedback on MVP. The figure has a cartoonish style, with lilac and purples hues and was create by Melissa Avila during the Epiverse-TRACE Summit 2023 in Bogotá."} + ::: {.callout-tip title="Read more about this principle in application"} - [Communicating development stages of open-source software](https://epiverse-trace.github.io/posts/comm-software-devel/) From 6086a6a9de112e52658cf5857e7f01594c8f6da9 Mon Sep 17 00:00:00 2001 From: Hugo Gruson <10783929+Bisaloo@users.noreply.github.com> Date: Thu, 15 Feb 2024 11:24:39 +0100 Subject: [PATCH 2/2] Add git merge strategies by Julia Evans --- git-branching-merging.qmd | 2 ++ 1 file changed, 2 insertions(+) diff --git a/git-branching-merging.qmd b/git-branching-merging.qmd index c0329f0..61893cd 100644 --- a/git-branching-merging.qmd +++ b/git-branching-merging.qmd @@ -72,6 +72,8 @@ GitHub currently has [3 pull request merge mechanisms](https://docs.github.com/e - Squash and merge - Rebase and merge +[![The 3 ways to combine branches in git: their differences, their respective benefits and drawbacks, by Julia Evans (@b0rk), CC BY-NC-SA 4.0.](https://wizardzines.com/images/uploads/combining-branches.png)](https://wizardzines.com/comics/combining-branches/) + The historical option 'merge commits' presents severe drawbacks, such as creating a heavily non-linear history, which is extremely difficult to read. Notably, it is very difficult to browse & understand a git history with merge commits in GitHub web interface. Yet, git history is a very precious source of information in older packages to inform new maintainers about the reasons behind some choices by old maintainers. For related reasons, merge commits can sometimes create flat out unintelligible diffs in pull requests.