Description

We want to have a first draft of our documentation on processes. This will be the first point of discussion on how we work remotely and asynchronously on this project. We will keep iterating on our processes and updating documentation.

We will create a new section in our Notion space for our documentation and fill it up. The main topics we want to tackle are the Development Process (mainly Pull Requests), the Definition of Done, the Definition of Ready, and our Team Agreements (e.g. we meet once a week to sync).

Acceptance Criteria

Create documents for:

• Definition of Ready
• Definition of Done
• Team Agreements
• Pull Requests process

Estimation/Complexity (S, M, L)

M

Priority (Low, Medium, High)

H

⚠️ This issue is blocked by #2 ⚠️

Problem definition

Currently the project is not sufficiently documented. We would like to add an overview for the project (what it is, what it's doing), an overview of the structure (how is the code organised, how do we achieve the goal?), and lastly how to run the application.

Goals

Have an up to date documentation of the project architecture and high level design

Acceptance Criteria

• Update Overview
• Update Description
• Update How to Use

Problem definition

This is a new project and as such it lacks structure, processes, and even a common understanding between the people involved. This project is to be used as a sandbox environment for improving online/remote collaboration as well as technical skills; we will, therefore, start off with best practices from our experience(s) and make adjustments as we go.
To get us going though we need a starting point, and this is it.

Goals

To create a structure for this project board so that we are aligned on a simple Kanban workflow. I propose having the following columns:

• To Do (a prioritised lists of all tickets)
• In Progress
• Done

I propose also having the following documents to define the "boundaries" for transitioning from one state to another:

• Definition of Ready (the criteria a ticket needs to fulfil to move to To Do)
• Definition of Done (the criteria a ticket needs to fulfil to move to Done)
• Team Agreements (defines when a ticket can move to In Progress, QA, etc.)
• How to Contribute (defines development processes like branch flow etc., defines pull request review process...)

I could also create a template for cards and issues, especially for tasks which involve development/coding. This is to standardise the task definition to make it easier to refine and also execute.
It might be possible to add this template in the repository/project so it's auto-loaded

Some parts of the documentation should live on GitHub (e.g. Readme.md) and some should stay in Notion. We should identify this split and already start putting things in the right place.

Acceptance Criteria

• Populate Readme document with basic documentation (TBD)
  • Project Structure (in code)
  • Project description
• Create Issue template

Description

What problem are we trying to solve? What do we want to do?
Why are we doing this Task?
What is the outcome of this Task?
How are you going to execute this Task (what are the steps)?
What relevant information should be written here to help understand and solve the problem?
Are there any side effects we need to consider?

Acceptance Criteria

What is the Definition of Done for this issue? List below every "box" we need to check

• [ ]

Estimation/Complexity (S, M, L)

Priority (Low, Medium, High)

Blockers or Pre-requisites

Is there anything blocking this issue? Is there some other work which needs to be completed before this issue?