docs(governance): Clarify terminology and repository references in governance documentation
All checks were successful
ci / build (push) Successful in 53s
All checks were successful
ci / build (push) Successful in 53s
This commit is contained in:
parent
67ef9d8c6e
commit
eeb623517b
1 changed files with 18 additions and 9 deletions
|
|
@ -37,6 +37,14 @@ Primary source (internal only): [Confluence: Sub Project Developer Framework](ht
|
|||
|
||||
The following phase model is based on the project artifacts currently present in Confluence and this repository. It is intentionally phrased as “what changed and why”, rather than as a release plan.
|
||||
|
||||
Terminology note: In this chapter, “Repository” refers to concrete Git repositories used as evidence sources. Unless stated otherwise:
|
||||
|
||||
- “Repository (this docs repo)” means this documentation repository (“website-and-documentation”), including `content/en/docs-old/`.
|
||||
- “Repository (edp-doc)” means the EDP technical documentation repository at (internal only) [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc).
|
||||
- “Confluence” refers to the IPCEI-CIS Confluence space on `confluence.telekom-mms.com` (internal only).
|
||||
|
||||
It does not refer to the wider set of platform/service code repositories unless explicitly stated.
|
||||
|
||||
#### Phase 1 — Discovery & system design (2024)
|
||||
|
||||
Focus:
|
||||
|
|
@ -60,7 +68,7 @@ Focus:
|
|||
Primary sources:
|
||||
|
||||
- Confluence (internal only): [Confluence: Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024)
|
||||
- Repository: docs-old PoC structure summary: [PoC Structure](../../docs-old/v1/project/plan-in-2024/poc/)
|
||||
- Repository (this repo): docs-old PoC structure summary: [PoC Structure](../../docs-old/v1/project/plan-in-2024/poc/)
|
||||
|
||||
#### Phase 3 — PoC consolidation: deliverables, repository structure, traceability (late 2024)
|
||||
|
||||
|
|
@ -70,7 +78,7 @@ Focus:
|
|||
- Make “traces” explicit from backlog items to concrete outputs (repos, docs, capabilities), to support governance and auditability.
|
||||
- Establish working agreements for branching, PR-based review, and Definition of Done.
|
||||
|
||||
Primary source: repository document [Team and Work Structure](../../docs-old/v1/project/team-process/) (docs-old).
|
||||
Primary source: repository document [Team and Work Structure](../../docs-old/v1/project/team-process/) (docs-old, in this repo).
|
||||
|
||||
#### Phase 4 — “Forgejo as a Service” and Foundry-based provisioning (2025)
|
||||
|
||||
|
|
@ -96,8 +104,8 @@ Focus:
|
|||
|
||||
Evidence:
|
||||
|
||||
- Repository: EdgeConnect documentation under `/docs/edgeconnect/` (SDK/client/actions).
|
||||
- Repository: docs-old “Publishing to Edge” describes the documentation deployment via `edgeconnectdeployment.yaml`.
|
||||
- Repository (this repo): EdgeConnect documentation under `/docs/edgeconnect/` (SDK/client/actions).
|
||||
- Repository (this repo): docs-old “Publishing to Edge” describes the documentation deployment via `edgeconnectdeployment.yaml`.
|
||||
|
||||
### Development and delivery process evolution
|
||||
|
||||
|
|
@ -122,8 +130,8 @@ The working model (used throughout the PoC) is:
|
|||
|
||||
Primary sources for the traceability intent:
|
||||
|
||||
- Repository: PoC design README lists Jira parts and calls for a mapping table from “parts” to upstream references.
|
||||
- Repository: team-process documents emphasize “traces from tickets to outputs” and an outcome summary in the ticket as part of Definition of Done.
|
||||
- Repository (edp-doc): PoC design README lists Jira parts and calls for a mapping table from “parts” to upstream references.
|
||||
- Repository (edp-doc): team-process documents emphasize “traces from tickets to outputs” and an outcome summary in the ticket as part of Definition of Done.
|
||||
|
||||
#### Matrix (evidence-backed overview)
|
||||
|
||||
|
|
@ -132,10 +140,10 @@ This matrix is intended to be directly consumable: it summarizes what can alread
|
|||
| Phase | What is delivered / proven | Concrete outputs (where) | Evidence / trace hooks |
|
||||
| --- | --- | --- | --- |
|
||||
| Phase 1 — Discovery & system design | Reference architecture framing and decision drivers | Confluence (internal only): [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) (planes model, CNOE baseline preference, dogfooding) | Architecture notes are the earliest “why” evidence for later component choices |
|
||||
| Phase 2 — PoC definition | PoC scope, acceptance criteria, end-to-end “golden path” story | Repository: PoC structure page (docs-old) and PoC design README | Jira parts exist for user docs + hands-on building blocks (see “Ticket anchors” below) |
|
||||
| Phase 3 — PoC consolidation & traceability | A packaged PoC with explicit traceability from backlog to outputs | Repository: PoC team-process guidance (Definition of Done, PR review, “traces”) | “Outcome” is expected to be summarized in the ticket with links to PR/commit artifacts |
|
||||
| Phase 2 — PoC definition | PoC scope, acceptance criteria, end-to-end “golden path” story | Repository (this docs repo): PoC structure page (docs-old) and Repository (edp-doc): PoC design README | Jira parts exist for user docs + hands-on building blocks (see “Ticket anchors” below) |
|
||||
| Phase 3 — PoC consolidation & traceability | A packaged PoC with explicit traceability from backlog to outputs | Repository (this repo): PoC team-process guidance (Definition of Done, PR review, “traces”) | “Outcome” is expected to be summarized in the ticket with links to PR/commit artifacts |
|
||||
| Phase 4 — Forgejo-as-a-Service + Foundry provisioning | A service milestone with operational concerns (persistence, backups, SSO, runners) and IaC provisioning | ADR (Scaleway as additional install channel) + postmortem (Foundry migration downtime) | Concrete operational evidence that architecture and migration risks were handled as governance work |
|
||||
| Phase 5 — EdgeConnect integration | EdgeConnect as delivery target and integration tooling | Repository: EdgeConnect docs section + docs-old “Publishing to Edge” (deployment yaml) | Deployment configuration and workflow description provide concrete “proof of use” |
|
||||
| Phase 5 — EdgeConnect integration | EdgeConnect as delivery target and integration tooling | Repository (this repo): EdgeConnect docs section + docs-old “Publishing to Edge” (deployment yaml) | Deployment configuration and workflow description provide concrete “proof of use” |
|
||||
|
||||
#### Ticket anchors (PoC)
|
||||
|
||||
|
|
@ -242,6 +250,7 @@ This list is an index of all links referenced on this page, plus the intended me
|
|||
- Service entry point: [edp.buildth.ing](https://edp.buildth.ing) — EDP Forgejo instance.
|
||||
- Service org: [edp.buildth.ing/DevFW-CICD](https://edp.buildth.ing/DevFW-CICD) — public organization referenced for transparency.
|
||||
- Service org: [edp.buildth.ing/DevFW](https://edp.buildth.ing/DevFW) — private organization reference.
|
||||
- (internal only) Repository (edp-doc): [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc) — EDP technical documentation repository (ADRs, postmortems, PoC process), used as evidence sources in this chapter.
|
||||
- Upstream project: [forgejo.org](https://forgejo.org/) — Forgejo project homepage.
|
||||
- Upstream governance: [Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/) — referenced as steward/governance body.
|
||||
- Upstream contribution: [PR #9409](https://codeberg.org/forgejo/forgejo/pulls/9409) — GARM endpoints contribution.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue