docs: 📝 Update team docs based on iteration retrospective

entries/admin.qmd

@@ -11,7 +11,7 @@ This contains details for general administration of projects. For the most part,
     [protect](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)
     the `main` branch of the repository to limit forced pushes and
     deletions. Within the branch protection settings, enable (check mark) these options in order to provide more security and checks to protect the `main` branch:
-    - "Require approvals", of at least 2 team members
+    - "Require approvals", of at least 1 team members
     - "Dismiss stale approvals when new commits are added"
     - "Allow specified actors to bypass requirements", the actor being the team leader
     - "Require approval of most recent reviewable push"

entries/iteration.qmd

@@ -19,8 +19,8 @@ However, often in academic and research settings, these assumptions are not rele
 Based on these inspirations, an iteration for us follows this general sequence of steps:
 
 1. Team lead sets everything up for the next two or three rounds.
-    - Will create a GitHub Project Board for the upcoming iteration using the ["Iteration" template](https://github.com/orgs/seedcase-project/projects/4).
-    - Will add the aim, output, as well as the end date of the iteration to be discussed and decided on in the first meeting.
+    - Will create an iteration within the main "Team project planning" board (which are all listed [here](https://github.com/orgs/seedcase-project/projects/), which is found in the Settings in the board.
+    - Will write the title of the iteration as the goal for it, while keeping the goal focused, small, acheivable, and considerate of the time we have available.
     - Will start adding some tasks into the board.
     - If possible, plan iterations so that they either end on a major holiday or are right in the middle of it. Don't plan the start of iterations a few days before major holidays start.
 

entries/update-meetings.qmd

@@ -10,9 +10,10 @@ each other updated on what everyone else is doing. Except, instead of
 daily, we have them twice-weekly. These are some guidelines on running these
 update meetings:
 
--   Keep meeting to \~30 minute
+-   Keep meeting to \~30 minutes.
 -   At the start of the meeting, the team lead will briefly share any
-    general updates or discussion points
+    general updates or discussion points.
+- Briefly review the iteration objective.
 -   Each person then gives an \~5 minute update that answers these
     items, in this order:
     1.  What did you do since the last update?
@@ -23,7 +24,7 @@ update meetings:
 -   Avoid getting into too much detail about any particular topic. See
     the guide entry on [communication](communication.qmd) about
     alternatives to these types of discussions.
-- Every Thursday's update meeting, we do an internal demo of a Pull Request or of the current state of the product.
+- Once a week (usually on Thursdays) during an update meeting, we'll internally do a demo of the current state of the project, either based on the main branch or on a Pull Request.
 
 Save any detailed or technical discussion on or about code for the [code
 review meetings](code-review-meetings.qmd).

events/2023-06-in-person/index.qmd

@@ -131,22 +131,22 @@ some topics and less on others.
             supplement with detailed enough comments, with a "top-level"
             comment describing the basic purpose, type of input, and
             type of output.
-    -   [ ] **Action**: Luke to put these into the contributing
+    -   **Action**: Luke will put these into the contributing
         document.
     -   For meetings:
         -   Use a template to cover some basic things that each person
             covers, in 5 minutes or less.
         -   Use "scrum standups" as inspiration.
-        -   [ ] **Action**: Luke will create templates we can follow.
+        -   **Action**: Luke will create templates we can follow.
 -   Struggles and barriers:
     -   What is the general design for the common data model?
     -   Using GitHub and Git
         -   Potential solution for this is create some workshops on
             using Git and GitHub. One for the basics and another for use
             in collaboration settings.
-        -   [ ] **Action**: Luke create two new repos on the
+        -   **Action**: Luke will create two new repos on the
             steno-aarhus account with basic setup for how it will look.
-        -   [ ] **Action**: Kris organize times with other Steno people
+        -   **Action**: Kris will organize times with other Steno people
             (Julie) on creating these workshops.
 -   Misc:
     -   Got domain name (`seedcase-project.org`) as well as a `.dk`
@@ -181,9 +181,9 @@ some topics and less on others.
         looks like, so we can identify sources of contribution.
 -   Start bringing together people who work on data on the management
     side (not analysis side).
-    -   [ ] **Action**: Kris to learn who is doing data management stuff
+    -   **Action**: Kris will learn who is doing data management stuff
         and coordinate bringing them together.
-    -   [ ] **Action**: Luke to start creating docs describing what we
+    -   **Action**: Luke will start creating docs describing what we
         are doing and why we are doing it and how to go about it.
 -   Start working more on the project listing/registration module of
     Seedcase, since others at Steno could benefit from that a lot. Would
@@ -192,5 +192,5 @@ some topics and less on others.
 -   Create a survey/form for people across Steno to submit ideas for
     projects or things we can help with, then we can start working on
     those one-by-one. And so we can start building up a wait list.
-    -   [ ] **Action**: Luke will create this and advertise it
+    -   **Action**: Luke will create this and advertise it
 

events/2023-10-in-person/index.qmd

@@ -110,9 +110,9 @@ I'll be creating a blog post about this experience, so won't add much here expec
     - Could either hire them after we have a core functional box or hire them to help use develop our process and workflow (getting started, project management, teamwork practices, "how to work" rather than "what to work on")
     - If hired for process, we'll need to give them clear requirements for what we want from them
         - We might need some time to sit down and define the requirements for designing the how to work together
-    - [X] Action: To contact them about hiring them, what are the next steps? How do they charge for their services?
-    - [ ] Action: Need to spend some time writing doc on how to work together, the process. This could be the next “focus stage”, on starting to write out a design document
-    - [ ] Action: Make a detailed list of what outputs we would like from them
+    - **Action**: To contact them about hiring them, what are the next steps? How do they charge for their services?
+    - **Action**: Need to spend some time writing doc on how to work together, the process. This could be the next “focus stage”, on starting to write out a design document
+    - **Action**: Make a detailed list of what outputs we would like from them
         - E.g. training material or documentation on working together and their process
         - E.g. finalize the design doc (maybe another review of it)?
 - Things we could take from them
@@ -128,7 +128,7 @@ I'll be creating a blog post about this experience, so won't add much here expec
         - Keep in mind the overall roadmap
         - Have a week of planning and deciding tasks
         - Then have a period of working on those tasks over the next month
-    - [ ] Action: Add these potential items / workflows to our team docs
+    - **Action**: Add these potential items / workflows to our team docs
 - Misc
     - We could include the timeline as part of our documentation
 
@@ -145,13 +145,13 @@ I'll be creating a blog post about this experience, so won't add much here expec
     - Building monthly sprints, with a period of roadmapping in those days
     - Use Kanban board with constrained time periods to use for the focus phases, with dedicated time pre-phase to describe and plan together what needs to be done and how long each task takes
     - Focus on smaller focused periods of working, with iterative development/feedback and smaller units of roadmapping.
-    - [ ] Action: Schedule time shortly 
+    - **Action**: Schedule time shortly 
     - Have twice-weekly update meetings
     - Limit external meeting
     - Make use of Issue’s
         - Issue templates for how to structure or fill in Issue/task
-        - [X] Action: Signe make the first draft of template
-    - [ ] Action: Make a PR template
+        - **Action**: Signe will make the first draft of template
+    - **Action**: Make a PR template
         - That includes a checklist of things to do
         - Including “has unit test been added”
     - Every update meeting comes with commit
@@ -162,13 +162,13 @@ I'll be creating a blog post about this experience, so won't add much here expec
     - Annelli will attend one of the update meetings, once a month
 - Tasks to do next
     - Converting over the digital copies and updating documentation
-        - [ ] Action: Signe and Kris will convert them
+        - **Action**: Signe and Kris will convert them
     - Focusing on diagrams and visualizations in design docs, and updating the existing ones and adding more ones
     - Have more definitions and lists on the definitions of terms
-    - [ ] Action: Build up Actions/CI
-    - [ ] Action: Pre-commits setup
-    - [ ] Action: Basic infrastructure for working together
-    - [ ] Action: Make issue template that includes a very detailed requirements for functionality (including input and output of functions/code)
+    - **Action**: Build up Actions/CI
+    - **Action**: Pre-commits setup
+    - **Action**: Basic infrastructure for working together
+    - **Action**: Make issue template that includes a very detailed requirements for functionality (including input and output of functions/code)
     - Review process?
         - PR
 - Misc items
@@ -177,21 +177,21 @@ I'll be creating a blog post about this experience, so won't add much here expec
     - Workflow, each project/package/app would have its own design doc and diagrams, etc?
 - Requirements for how to work together effectively as a team
     - Shorter-term roadmap (e.g. 3 month cycle, 6 month cycle, 1 year cycle)
-        - [X] Action: Luke update roadmap and convert into milestones on the docs but also on GitHub as a Milestone 
+        - **Action**: Luke will update roadmap and convert into milestones on the docs but also on GitHub as a Milestone 
     - (see items above)
-    - [ ] Action: Setup pre-commit hooks?
+    - **Action**: Setup pre-commit hooks?
         - Pre-commit for unit tests?
         - Pre-commit for a website? Render?
         - Format markdown (lint only)
         - Format code (lint only)
         - Spellchecker
-    - [ ] Action: Flesh out the Justfile
+    - **Action**: Flesh out the Justfile
         - Format markdown and code
-    - [ ] Action: PR template
+    - **Action**: PR template
         - Checklist
             - Run formatters?
             - Unit tests included?
-    - [ ] Action: Create/use a devcontainer
+    - **Action**: Create/use a devcontainer
         - psql
         - jq (for ndJSON file), Python package?
         - Black
@@ -203,4 +203,4 @@ I'll be creating a blog post about this experience, so won't add much here expec
         - Poetry for Python environments?
     - Git Flow
         - Multiple commits per day, at minimum push at end of work day
-        - [ ] Action: Signe finish that up
+        - **Action**: Signe will finish that up