This commit is contained in:
Stephan Lo 2024-11-18 22:37:37 +01:00
parent 206f67d33c
commit bd4672c103
10 changed files with 75 additions and 12 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 376 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 218 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 652 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 726 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 888 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 522 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 256 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 624 KiB

View file

@ -1,38 +1,101 @@
---
title: Team and Work Process
title: Team and Work Structure
weight: 50
description: The way we work
description: The way we work and produce runnable, presentable software
linkTitle: Team-Process
---
## Rationale
## Structure
This document describes a proposal to set up a team work structure to primarily get the POC successfully delivered. In the latter we will adjust and refine the process to fit for the MVP.
### General working context
We are a **team** and create in an agile manner **output** to fulfill a **project goal**. The **backlog** holds the specification by which we imperatively manufacture by use of **tasks**.
![alt text](./_assets/P1.png)
### POC and MVP working context
Today is mid november 2024 and we need to package our project results created since july 2024 to deliver the POC product.
![alt text](./_assets/P2.png)
> Think of the agenda's goal like this: Imagine Ralf the big sponsor passes by and sees 'edge Developer Framework' somewhere on your screen. Then he asks: 'Hey cool, you are one of these famous platform guys?! I always wanted to get a demo how this framework looks like!' \
> **What are you going to show him?**
## Team and Work Structure (POC first, MVP later)
In the following we will look at the work structure proposal, primarily for the POC, but reusable for any other release or the MVP
### Consolidated POC (or any release later)
![alt text](./_assets/P3.png)
#### Responsibilities to reliably specify the deliverables
![alt text](./_assets/P4.png)
### Todos
1. a
1. b
1. c
### Process (General): from deliverables to output (POC first, MVP later)
![alt text](./_assets/P5.png)
### Output Structure POC
![alt text](./_assets/P6.png)
### Work Structure Guidelines (POC first, MVP later)
#### Structure
1. each task and/or user story has at least a branch in an existing repo or a new, dedicated task repo
> recommended: multi-repo over monorepo
1. each repo has a main and development branch. development is the intgeration line
1. pull requests are used to merge work outputs to the integration line
1. optional (my be too cumbersome9: each PR should be reflected as comment in jira
1. optional (my be too cumbersome): each PR should be reflected as comment in jira
## Workflow
#### Workflow
* `git init` --> always create as fast as possible a new repo
1. `git init` --> always create as fast as possible a new repo
1. commit early and oftenly
1. comment on tickets
## Definition of Done
#### Definition of Done
1. Jira: there is a final comment summarizimg the outcome (in a bit more verbose from than just the 'resolution' of the ticket) and the main outputs. This may typically be a link to the commit and/or pull request of the final repo state
2. repo: there is a README.md in the root of the repo. It summarizes in a typical Gihub-manner how to use the repo, so that it does what it is intended to do and reveals all the bells and whistles of the repo to the consumer. If the README doesn't lead to the usable and recognizable added value the work is not done!
## Review
#### Review
* Before a ticket gets finished (not defined yet which jira-state this is) there must be a review by a second team member
* the reviewing person may review whatever they want, but must at least check the README
1. Before a ticket gets finished (not defined yet which jira-state this is) there must be a review by a second team member
1. the reviewing person may review whatever they want, but must at least check the README
## Out of scope (for now)
#### Out of scope (for now)
The following topics are optional and do not need an agreement at the moment:
1. Commit message syntax
> Recommendation: at least 'WiP' would be good if the state is experimental
1. branch permissions
1. branch clean up policies
1. squashing when merging into the integration line
1. squashing when merging into the integration line
1. CI
1. Tech blogs / gists
1. Changelogs
#### Integration of Jira with Forgejo (compare to https://github.com/atlassian/github-for-jira)
1. Jira -> Forgejo: Create Branch
1. Forgejo -> Jira:
1. commit
2. PR
## Status of POC Capabilities
![alt text](./_assets/P8.png)

Binary file not shown.

After

Width:  |  Height:  |  Size: 166 KiB