In-person workshop and team meeting

Details and agenda for our in-person workshop with Mjølner and our post-workshop debrief and meeting.

Luke W. Johnston


October 23, 2023


  • Dinners for Oct 23 and Oct 24.
  • 2-days at Mjølner in Aarhus and one at Forum (rooms in calendar invite).
  • Main aim of workshop:
    • Get feedback on our overall design.
    • Discuss and decide on how/if they can work with us and what they can provide or do.
  • Main aim of debrief and meeting:
    • Debrief from the workshop, anything to add to design/plan, items of contention or disagreement, how we can work with them
    • Discuss struggles/challenges and next steps


The schedule is meant as a guide only. We might spend more time on some topics and less on others.

Day 1: Oct 23

Time Item
08:30 Introduction of participants & agenda for the two days
09:00 EventStorming introduction & Part 1 (as-is for current system)
10:00 Break
10:15 EventStorming Part 1
11:45 Lunch & coffee refill
12:15 EventStorming Part 2
13:45 Break
14:00 EventStorming Part 3
15:30 Day 1 Wrap Up

Day 2: Oct 24

Time Item
08:30 Welcome and coffee acquisition
08:45 Introduction of Seedcase
09:30 Vision for Seedcase
10:15 Break
10:30 User Stories for Seedcase
11:15 Prioritize User Stories
11:45 Lunch & coffee refill
12:15 Tech track deep dive
14:00 Break
14:15 Feedback & Recap
15:00 Thank you for today

Day 3: Oct 25

Time Item
09:30 Unstructured discussion and debrief
12:00 Lunch
12:45 Next steps
15:00 End of day (or earlier)


Workshop with Mjølner

  • They will lead these two days.

Next steps, barriers, and other items

  • Areas of struggle or barriers?
    • Discussion on why progress has been slow.
    • What are some things we need to improve on?
  • Idea for team workflow:
    • Focused work on individual projects on a rotation basis. For example, one month is on seedcase-registry, another is on team. We could rotate between one month core activity followed by a two week focus on smaller projects (like volunteer database).


Workshop with Mjølner

I’ll be creating a blog post about this experience, so won’t add much here expect some misc items.

  • Comments from them:
    • What about backups of the data? In the Docker container or somewhere else?
    • Is it something to add to docs or is it a feature?
    • Transferring data to servers is a lot more difficult than it seems, so best have that as many versions in the future (if at all)
    • A lot of language we used was about “limiting access”, but it might be useful to use language on “enabling access”
    • Be careful about store logs too much, they can quickly bloat
    • How to handle backward compatibility? Part of testing to include tests of demo?
  • We need to get some fake/public data or something to use for demo and test purposes

Workshop debrief:

  • General comments
    • Obvious they have skill in frontend dev, based on what they showed us
    • Can’t judge what their security capabilities or backend capability are though
    • They had good process/flow for guiding us, they kept good pace and kept on time
    • They were very professional and friendly to work with, good seniority/experience for them
    • Obvious they had read up on what we were doing and were prepared
    • Helped us to focus down on what things would be version 1 vs later versions, as well as identifying hotspots and things to move on with
    • It was really useful to see how they work as well, though maybe not loving the purely scrum style they use
  • Hiring them and what/how they can work with us
    • 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
    • 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
    • Their approach to visualizing things (e.g. for instance with the vertical lines)
      • For virtual settings: Look into online tools (they use Figma) that help with doing the visualize
    • Making sure everything is visible (can’t talk about things that are invisible)
    • Clearer and more descriptive “events”
    • Having time during meetings to dig into “user stories”/tasks
      • Including adding some time estimates
      • Every certain frequency, like every month
      • Use them as the basis for a “focus” period
    • Flow
      • 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
  • Misc
    • We could include the timeline as part of our documentation

Update on progress, barriers and challenges

  • Getting lost down learning rabbit hole
  • Not having a clear path forward on what to work on
  • Feeling a bit managed vs led
  • Trust needs building up

Next steps to push progress forward

  • Moving forward, tracking progress, and building trust
    • 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
    • Have twice-weekly update meetings
    • Limit external meeting
    • Make use of Issue’s
      • Issue templates for how to structure or fill in Issue/task
      • 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
    • Nothing pushed to main, it has to go through PR and review
    • If one of us are assigned or asked for review, work on it
    • Always have someone assigned to everything
    • Not working on side projects
    • 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
    • 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)
    • Review process?
      • PR
  • Misc items
    • Ask Mjolner SQL injection (and looking into things)
    • Frictionless data, pull it in?
    • 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)
      • 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?
      • 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
      • Format markdown and code
    • Action: PR template
      • Checklist
        • Run formatters?
        • Unit tests included?
    • Action: Create/use a devcontainer
      • psql
      • jq (for ndJSON file), Python package?
      • Black
      • Justfile
      • Quarto
      • PostgreSQL
      • Python
      • Django
      • Poetry for Python environments?
    • Git Flow
      • Multiple commits per day, at minimum push at end of work day
      • Action: Signe will finish that up