WiP
BIN
content/en/docs/project/team-process/_assets/P1.png
Normal file
|
After Width: | Height: | Size: 376 KiB |
BIN
content/en/docs/project/team-process/_assets/P2.png
Normal file
|
After Width: | Height: | Size: 218 KiB |
BIN
content/en/docs/project/team-process/_assets/P3.png
Normal file
|
After Width: | Height: | Size: 652 KiB |
BIN
content/en/docs/project/team-process/_assets/P4.png
Normal file
|
After Width: | Height: | Size: 726 KiB |
BIN
content/en/docs/project/team-process/_assets/P5.png
Normal file
|
After Width: | Height: | Size: 888 KiB |
BIN
content/en/docs/project/team-process/_assets/P6.png
Normal file
|
After Width: | Height: | Size: 522 KiB |
BIN
content/en/docs/project/team-process/_assets/P7.png
Normal file
|
After Width: | Height: | Size: 256 KiB |
BIN
content/en/docs/project/team-process/_assets/P8.png
Normal file
|
After Width: | Height: | Size: 624 KiB |
|
|
@ -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**.
|
||||
|
||||

|
||||
|
||||
### 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.
|
||||
|
||||

|
||||
|
||||
> 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)
|
||||
|
||||

|
||||
|
||||
#### Responsibilities to reliably specify the deliverables
|
||||
|
||||

|
||||
|
||||
### Todos
|
||||
|
||||
1. a
|
||||
1. b
|
||||
1. c
|
||||
|
||||
### Process (General): from deliverables to output (POC first, MVP later)
|
||||
|
||||

|
||||
|
||||
### Output Structure POC
|
||||
|
||||

|
||||
|
||||
### 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
|
||||
|
||||

|
||||
BIN
content/en/docs/project/team-process/image.png
Normal file
|
After Width: | Height: | Size: 166 KiB |