Update few files

principles.qmd

@@ -41,13 +41,13 @@ Useful software development is unlikely to be achieved by developers alone: rath
 
 ## Lean and Agile collaboration framework
 
-The main objective of our collaboration framework will be to optimize interactions between users and developers. We thus naturally embrace the agile philosophy in which projects progress iteratively through short cycles focussing on delivering and reviewing MVPs. We foresee that each cycle should have three main phases:
+The main objective of our collaboration framework will be to optimize interactions between users and developers. We thus naturally embrace the agile philosophy in which projects progress iteratively through short cycles focusing on delivering and reviewing MVPs. We foresee that each cycle should have three main phases:
 
 1. *Planning*: users and developers write a backlog of tasks to complete, identify top priorities, and define which MVPs will be worked on in the production phase
 2. *Production*: developers produce MVPs; if pair-programming is used, users could be involved at this stage too
 3. *Review*: presentation of MVPs and collection of feedback; the backlog is updated accordingly; this is also the opportunity for a retrospective assessment of the process: What was done well? What caused problems? How can the team improve the work process?
 
-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.
+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 (which can be created through the **Projects** tab on GitHub) 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á."}
 
@@ -88,14 +88,14 @@ Key principles include:
 - Consider code reviews as a non-hierarchical exercise, performed by all members of the developers team.
 - Understand that code reviews are a great opportunity for training and collaboration
 - Consider Alex Hill’s [quadrant of code reviews](https://www.alexandra-hill.com/2018/06/25/the-art-of-giving-and-receiving-code-reviews/) when conducting reviews and treat separately:
-  - Most code quality issues can be solved with automation (*e.g.* styling with [lintr](https://lintr.r-lib.org/), [styler](https://styler.r-lib.org/), or [goodpractice](https://mangothecat.github.io/goodpractice/))
-  - Non-conflictual, factual issues can be quickly agreed on (*e.g.* missing tests, typos in the documentation)
-  - Spend time to discuss high-conflict, high-reward items, and take a collaborative approach to identifying solutions
-- Use pair-programming sessions when developing features to foster a sense of code co-ownership and peer learning
+  - Most code quality issues can be solved with automation (*e.g.* styling with [lintr](https://lintr.r-lib.org/), [styler](https://styler.r-lib.org/), or [goodpractice](https://mangothecat.github.io/goodpractice/)).
+  - Non-conflictual, factual issues can be quickly agreed on (*e.g.* missing tests, typos in the documentation).
+  - Spend time to discuss high-conflict, high-reward items, and take a collaborative approach to identifying solutions.
+- Use pair-programming sessions when developing features to foster a sense of code co-ownership and peer learning.
 - Make code reviews an intrinsic part of the contribution workflow: they are typically performed [as part of the PR review process](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request).
 - Use code walk-throughs ahead of reviews to facilitate the review process.
-- Prefer small reviews to large ones
-- Conduct occasional audits of the entire code base
+- Prefer small reviews to large ones.
+- Conduct occasional audits of the entire code base.
 
 ::: {.callout-tip title="Read more about this principle in application"}