website-and-documentation/content/en/docs/project/team-process/_index.md

title	weight	description	linkTitle
Team and Work Structure	50	The way we work and produce runnable, presentable software	Team-Process

Rationale

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
2. b
3. 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

2. each repo has a main and development branch. development is the intgeration line
3. pull requests are used to merge work outputs to the integration line
4. optional (my be too cumbersome): each PR should be reflected as comment in jira

Workflow

1. git init --> always create as fast as possible a new repo
2. commit early and oftenly
3. comment on tickets

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

1. Before a ticket gets finished (not defined yet which jira-state this is) there must be a review by a second team member
2. the reviewing person may review whatever they want, but must at least check the README

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

2. branch permissions
3. branch clean up policies
4. squashing when merging into the integration line
5. CI
6. Tech blogs / gists
7. Changelogs

Integration of Jira with Forgejo (compare to https://github.com/atlassian/github-for-jira)

1. Jira -> Forgejo: Create Branch
2. Forgejo -> Jira:
   1. commit
   2. PR

Status of POC Capabilities