Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add illustrations #79

Merged
merged 2 commits into from
Feb 15, 2024
Merged

Add illustrations #79

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f058eeb
Add agile figure from Melissa
Bisaloo Feb 15, 2024
6086a6a
Add git merge strategies by Julia Evans
Bisaloo Feb 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions git-branching-merging.qmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 2 additions & 0 deletions principles.qmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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/)
Expand Down
Loading