Governance
Project history, decision context, and audit-oriented traceability (primary sources and evidence).
Governance Overview
This chapter is publicly accessible, but it is written from within the IPCEI-CIS project context and therefore builds heavily on internal shared understanding.
Most terminology, references, and primary sources in this chapter are internal (e.g., Confluence, Jira). Access and context are assumed.
Primary intended audience:
- IPCEI-CIS auditors
- IPCEI-CIS project management
- Project leads of other IPCEI-CIS sub-projects
- IPCEI-CIS central architecture
1 - Project history
Mandate, phases, milestones, and process evolution.
Mandate and product vision
Within the IPCEI-CIS work package for an Edge Developer Framework, the goal of the Developer Framework / EDP effort is to provide services that enable teams to develop, validate, roll out and operate applications efficiently across the edge cloud continuum.
The initial product framing emphasized:
- A coherent developer experience spanning development, testing, validation, rollout, monitoring and (eventually) billing.
- Reuse through templates and “golden paths”.
- A portal-centric interaction model where developers consume platform capabilities via stable APIs and UI, not ad-hoc cluster access.
Primary source (internal only): Confluence: Sub Project Developer Framework
Phases and milestones
The following phase model is derived from the documented primary sources referenced in this chapter (Confluence and the referenced repositories). The phrasing focuses on “what changed and why”; it is not a release plan.
Terminology: 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
/docs-old/. - “Repository (edp-doc)” means the EDP technical documentation repository at (internal only) 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:
- Establish a reference architecture for an Internal Developer Platform (IDP) style solution.
- Evaluate IDP foundations (explicitly referencing CNOE as a favored baseline), using a “planes” model as conceptual structure.
- Early emphasis on becoming self-hosting quickly (“eat your own dogfood”) and validating end-to-end paths.
Primary source (internal only): Confluence: System Design
Phase 2 — Proof of Concept (PoC) definition and scope (2024)
Focus:
- Align on a shared understanding of the product “Developer Platform” (technical and business framing) and what is feasible within 2024.
- Define PoC goals and acceptance criteria, including an end-to-end story centered on:
- an IDP builder/orchestrator running in the target environment (OSC),
- a developer portal (Backstage) for the user experience,
- a “golden path” flow from source → CI/CD → deployment.
Primary sources:
Phase 3 — PoC consolidation: deliverables, repository structure, traceability (late 2024)
Focus:
- Package outputs produced since mid-2024 into a demonstrable PoC product.
- 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, in this repo).
Phase 4 — “Forgejo as a Service” and Foundry-based provisioning (2025)
Focus:
- Expand from “PoC capabilities” toward a service milestone around Forgejo, including supporting services (persistence, backups, caching, indexing, SSO, runners, observability).
- Provision Foundry/EDP resources via Infrastructure-as-Code, initially in OTC.
- Address reliability and migration risks while moving from earlier instances to production endpoints.
Evidence:
- Confluence (internal only): Confluence: Forgejo as a service (service decomposition and operational concerns)
- ADR: “Add Scaleway as Cloud resource Provider” explicitly places Foundry/EDP IaC provisioning in mid-April 2025 and captures platform issues and mitigation.
- Postmortem (2025-07-14) documents downtime rooted in an incomplete Foundry migration and the need for explicit migration plans.
Focus:
- Treat EdgeConnect as a sovereign deployment target operated outside EDP, and provide consumable tooling to integrate it into delivery workflows.
- Provide reusable automation components (SDK, CLI client, Terraform provider, Forgejo Actions) so that EdgeConnect is used consistently through stable entry points.
- Use EdgeConnect for deploying project artifacts (including this documentation website) to edge cloudlets.
Evidence:
- 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.
Focus:
- Ship the first production-grade AI-native tooling layer for EdgeConnect (MCP Server).
- Harden the EDP platform: security posture, platform upgrade, and operational reliability.
- Complete the runner resource optimization PoC, giving teams data-driven right-sizing recommendations.
- Deliver use-case examples that lower the onboarding barrier for EdgeConnect customers.
- Continue upstream open-source contributions to Forgejo (ephemeral runners, webhook triggers).
MCP Server for EdgeConnect (IPCEICIS-6969, IPCEICIS-7085)
The Edge Connect MCP Server reached a production milestone in Q1 2026. It exposes all App and AppInstance CRUD operations through the Model Context Protocol, letting AI assistants such as Claude Desktop and Claude Code manage EdgeConnect resources through natural language.
The Q1 delivery shipped:
- Local stdio transport for desktop AI clients
- Full App and AppInstance CRUD (create, list, show, update, delete, refresh)
- OAuth 2.1 / JWT authentication for remote deployments
- Rich HTML dashboards via MCP-UI alongside structured JSON responses
- Installation and usage documentation at /docs/edgeconnect/edge-connect-mcp/
Evidence:
GARM provider for EdgeConnect (IPCEICIS-5752, IPCEICIS-5755)
The GARM Edge Connect provider was completed, enabling ephemeral Forgejo Actions runners to be dynamically provisioned as Kubernetes pods on EdgeConnect cloudlets. This allows CI/CD capacity to scale elastically across edge locations with automatic resource cleanup after each job.
Evidence:
Forgejo 14 upgrade (IPCEICIS-7848)
The EDP production instance at edp.buildth.ing was upgraded to Forgejo 14 in Q1 2026. This resolved outstanding version lag and enabled adoption of the latest upstream GARM integration features.
Security hardening (IPCEICIS-8008, IPCEICIS-8009, IPCEICIS-8011, IPCEICIS-8012)
A dedicated security hygiene epic was executed across Q1 2026, delivering:
- Multi-Factor Authentication (MFA): MFA enabled and enforced for EDP platform users
- Forgejo administration cleanup: Removal of redundant admin accounts and service accounts; access reviewed and tightened
- Trivy scan automation: Automated container and dependency vulnerability scanning integrated into EDP pipelines via a Forgejo Action, with results uploaded to Dependency-Track
Runner resource optimization PoC (IPCEICIS-6887, IPCEICIS-7421, IPCEICIS-7413)
A proof-of-concept was completed that analyses historical CPU and memory utilization from CI/CD pipeline runs to recommend right-sized runner configurations. The smallest runner that covers the peak usage with a 20% safety margin is surfaced — without auto-enforcing changes.
Alongside this, a runner sustainability dashboard was shipped into Forgejo’s runner settings page, showing which runners were used per job, historical usage trends, and current runner statuses for per-project sustainability tracking.
Evidence:
EdgeConnect use-case examples (IPCEICIS-7280, IPCEICIS-7281, IPCEICIS-7285)
To accelerate customer onboarding, several use-case deliverables were produced:
- An example application with database access was created and documented, demonstrating end-to-end deployment of a stateful application on EdgeConnect
- API interaction overview materials (slides and documentation) were produced showing the full breadth of ways to interact with EdgeConnect — CLI, SDK, Terraform, Actions, MCP Server
Evidence:
Redis reliability fix (IPCEICIS-7398)
Redis (the Distributed Cache Service used by Forgejo on OTC) regularly reached capacity under active crawling loads, causing 500 errors across Forgejo operations. A cloud function was created to automatically clear Redis when it approaches capacity, with an OTC Cloud Eye alarm and notification channel triggering it. This eliminates the need for manual intervention to restore Forgejo availability.
Forgejo upstream contributions (IPCEICIS-6557)
Open-source contributions to the upstream Forgejo project continued in 2026, including follow-up on previously merged PRs and tracking of new PRs:
Development and delivery process evolution
Across the phases above, delivery methods and team process evolved in response to scaling and operational needs:
- Scrum ceremonies and working agreements are documented in Confluence (internal only): Confluence: Scrum working agreement.
- Collaborative delivery techniques (mob / ensemble programming) appear as an explicit practice, including in incident documentation (“Team: Mob”) and internal guidance on sustainable mobbing models.
Team enablement and skill development (PII-free synthesis)
This section summarizes team enablement and skill development, based on the project’s documented sources, and is presented without personal data:
- Baseline skill assumptions: Kubernetes and GitOps are foundational. The platform architecture explicitly uses Kubernetes and a CNOE-derived stacks concept (see Platform Orchestration).
- Enablement/training happened as part of delivery (not a separate “academy”): retrospectives and planning explicitly track knowledge-sharing sessions and training topics (internal only, see References).
- Kubernetes enablement: a Kubernetes introduction training was planned as part of team onboarding/enablement activities (internal only; see References).
- Go as a relevant skill: multiple components are implemented in Golang (e.g., EdgeConnect tooling, Forgejo). Internal material discusses Golang developer skill profiles; this docs repo does not contain a single, explicit record of a dedicated “Go training” event.
- Skill leveling via collaboration: Mob Programming is used as a deliberate practice for knowledge sharing and onboarding less experienced developers (see Forgejo docs entry).
See also: the central References index.
2 - Traceability
Deliverables mapping, evidence model, matrix overview, and ticket anchors.
Deliverables mapping
This section captures the traceability model and evidence-backed anchors that connect capabilities/phases to concrete outputs (repositories, documentation pages, deployed services). It does not yet claim a complete IPCEI deliverable-ID → epic → artifact mapping.
Traceability model (used for audit)
The working model (used throughout the PoC) is:
- Deliverable / capability definition (often in Confluence) →
- Ticket(s) in Jira / Forgejo →
- Implementation via commits + pull requests →
- Concrete output (repo, docs page, automation component, deployed service) →
- Evidence (ADR / postmortem / runbook / deployment config) showing real operation.
Primary sources for the traceability intent:
- 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)
This matrix is intended to be directly consumable: it summarizes what can already be evidenced from the current sources. It is an overview across phases/capabilities; it is not the full IPCEI deliverable-ID mapping.
| 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 (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 (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 docs 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 (this docs repo): EdgeConnect docs section + docs-old “Publishing to Edge” (deployment yaml) | Deployment configuration and workflow description provide concrete “proof of use” |
Ticket anchors (PoC)
The PoC design README explicitly provides Jira anchors that can be used to build a full traceability matrix:
Related docs-old pages referenced by the history and matrix:
See also: the central References index.
3 - Compliance & audit
Technology choices, auditability, and external relations.
Technology Choices
Documentation of technology evaluation and selection process for key components (e.g., VictoriaMetrics, GARM, Terraform, ArgoCD).
Forgejo
The internal service is officially designated as the Edge Developer Platform (EDP). It is hosted at edp.buildth.ing. The domain selection followed a democratic team process to establish a unique identity distinct from standard corporate naming conventions.
Solution selection:
The decision to utilize Forgejo as the core self-hosted Git service was driven by specific strategic requirements:
- EU-Based Stewardship: Forgejo is stewarded by Codeberg e.V., a non-profit organization based in Berlin, Germany. This alignment ensures compliance with GDPR and data sovereignty requirements, placing governance under EU jurisdiction rather than US tech entities.
- License Protection (GPL v3+): Unlike “Open Core” models, Forgejo uses a copyleft license. This legally protects custom extensions developed in this project (such as GARM support) from being appropriated into proprietary software, ensuring the ecosystem remains open.
- Open Source Strategy: The platform aligns with the “Public Money, Public Code” philosophy, mandating that funded developments are returned to the community.
Access Model:
The platform operates on a hybrid visibility model:
- Public Access: The
DEVFW-CICD organization is publicly accessible, fostering transparency. - Private Access: Sensitive development occurs in restricted organizations (e.g.,
DEVFW). - User Base: Primary users include the internal development team, with friendly user access granted to the IPCEI team and MMS BT.
Ticket References
Cross-references to Jira tickets, epics, and project tracking for audit trails.
Current, evidence-backed anchors:
- PoC “parts” and hands-on scope are anchored in Jira and listed explicitly in the PoC design README (see Traceability / Ticket anchors).
- PoC consolidation and governance intent (“traces from tickets to outputs”) is described in the team-process documentation.
- The Forgejo ProjectMgmt prototype documents how tickets, milestones, and boards were structured in Forgejo to run demo slices and work packages.
Open Source Contributions
Contributions to the Forgejo community and other open-source projects.
Forgejo
Project extensions were contributed upstream to the Forgejo project on Codeberg.org.
Key Pull Requests:
- API Compatibility: Added GitHub-compatible endpoints for runner registration.
- Webhook Support: Implemented webhook triggers for workflow events.
- Ephemeral Runners: Added support for runners that terminate after a single job.
External Stakeholders
From the beginning, the project used structured stakeholder formats to collect requirements, validate assumptions, and strengthen a product-development mindset beyond “pure delivery”.
Evidence (internal only):
- Stakeholder workshop planning and target groups are captured in Confluence: eDF Stakeholder Workshops (internal/external workshops, goals, and intended outcomes).
- A concrete external workshop session is documented in Confluence: external stakeholder workshop (incl. agenda attachment). Note: the page explicitly contains AI-generated content and should be verified.
- An internal workshop session with detailed agenda and feedback is documented in Confluence: internal stakeholder workshop 7.11. (also includes AI-generated summary blocks).
Key decisions and learnings (PII-free synthesis)
The workshop and research artifacts consistently point to a few pragmatic decisions and product learnings (summarized here without personal data):
- Onboarding is a primary adoption gate: prioritize low cognitive load, clear guidance, and a “cold start” path that works without prior context (captured in the Customer Engagement plan and related onboarding-focused activities).
- Treat navigation and information architecture as product work: “too many clicks”, missing global orientation cues, and inconsistent navigation were recurring friction points; prioritization leaned towards making “projects / work” more discoverable and first-class (see UX insights log for navigation/IA patterns).
- Forgejo PM & Docs need either redesign or deliberate scope boundaries: modern PM/docs workflows and stakeholder reporting expectations were a known gap; this informed decisions about prototyping and scoping improvements vs. relying on integrations.
- Expect a tension between autonomy and guardrails: research highlights that developer autonomy is valued while guardrails increase trust and repeatability; positioning matters because “platform” concepts can be perceived as top-down control if not framed carefully.
- Institutionalize UX feedback loops: beyond ad-hoc workshops, the work moved towards a repeatable research cadence (panel/community, surveys, and insight logging) to reduce “one-off feedback” risk.
- Automated UX testing was formalized as a concrete use case: a dedicated “use case identification” artifact structures automated UX testing around functional correctness, visual consistency/accessibility, and task-based end-to-end “happy path” flow checks (used as input for the later UX work package stream).
Later, a dedicated “user experience” focus was strengthened and formalized via a dedicated work package / deliverable stream that explicitly frames UX validation as an activity with objectives, KPIs, and user validation:
See also: the central References index.
4 - References
Index of primary sources and evidence links used across the Governance chapter.
This list is an index of links referenced across the Governance chapter, plus the intended meaning (“semantics”) of each link.
- (internal only) Confluence: Sub Project Developer Framework — mandate, quick links, and high-level framing.
- (internal only) Confluence: System Design — architecture framing (planes model, baseline preferences, early decision drivers).
- (internal only) Confluence: Proof of Concept 2024 — PoC scope, goals, and evaluation/acceptance framing.
- (internal only) Confluence: Forgejo as a service — service decomposition and operational concerns used as evidence for Phase 4.
- (internal only) Confluence: Scrum working agreement — delivery process reference.
- (internal only) Confluence: Knowledge sharing sessions — planning table of internal enablement sessions (training topics and facilitation). Note: contains personal data; use only for PII-free synthesis.
- (internal only) Confluence: Retro: How to improve our work — retrospective notes including explicit calls for Kubernetes training sessions and documentation/working-agreement improvements. Note: contains personal data; use only for PII-free synthesis.
- (internal only) Confluence: Retro 15/04/25 — retrospective notes showing iteration on ticket sizing, async refinement, and meeting overhead; also references “Knowledge sharing sessions”. Note: contains personal data; use only for PII-free synthesis.
- (internal only) Confluence: Retro 13/05/25 — retrospective notes explicitly discussing mobbing practices (roles, breaks, splitting mob groups) and knowledge exchange. Note: contains personal data; use only for PII-free synthesis.
- (internal only) Confluence: Research Paper Mob Programming — internal background material on mob programming practices and trade-offs. Note: treat as internal working material.
- (internal only) Confluence: eDF Stakeholder Workshops — plan for internal/external stakeholder workshops, target groups, and intended outcomes.
- (internal only) Confluence: internal stakeholder workshop 7.11. — internal stakeholder session agenda and captured feedback (contains AI-generated summary blocks).
- (internal only) Confluence: external stakeholder workshop — external stakeholder session notes (contains agenda attachment and AI-generated summary blocks).
- (internal only) Confluence: Workpackage e.3 - Sustainable-edge-management-optimized user interface for edge developers — UX-focused workpackage with objectives, KPIs, and “validation with users” framing.
- (internal only) Confluence: Deliverable D66 - Sustainable-edge-management-optimized user interface for edge developers — deliverable page including PoC results summary for autonomous UI/UX testing.
- (internal only) Confluence: Customer Engagement — research planning cadence (who/why/when), plus synthesized insights/assumptions used to justify PII-free learnings summaries.
- (internal only) Confluence: UX Insights and Learnings — running log of UX observations and recommended improvements (useful for evidence-backed, non-PII synthesis of recurring friction patterns).
- (internal only) Confluence: [IPCEICIS-3703] Use Case identification for automated UX testing — structured prioritization of automated UX testing scenarios (happy-path smoke flows, functional correctness, visual/accessibility checks). Note: treat as internal working material; do not replicate embedded credentials/content.
- (internal only) Jira: IPCEICIS-368 — PoC part 1 traceability anchor.
- (internal only) Jira: IPCEICIS-765 — PoC part 2.1 traceability anchor.
- (internal only) Jira: IPCEICIS-766 — PoC part 2.2 traceability anchor.
- (internal only) Jira: IPCEICIS-514 — PoC golden path template traceability anchor.
- (internal only) Jira: IPCEICIS-759 — PoC example app traceability anchor.
- (internal only) Jira: IPCEICIS-760 — PoC CI/CD traceability anchor.
- (internal only) Jira: IPCEICIS-761 — PoC telemetry traceability anchor.
- (internal only) Jira: IPCEICIS-762 — PoC infrastructure traceability anchor.
- (internal only) Jira: IPCEICIS-763 — PoC additional items traceability anchor.
- (internal only) Jira: IPCEICIS-767 — PoC orchestration extension traceability anchor.
- (internal only) Jira: IPCEICIS-768 — PoC part 3 (user documentation) traceability anchor.
- Documentation site: PoC Structure — published docs-old summary of the PoC structure.
- Documentation site: Team and Work Structure — published docs-old description of process and traceability intent.
- Documentation site: Forgejo docs entry — documentation entry point for the Forgejo/EDP component.
- Service entry point: edp.buildth.ing — EDP Forgejo instance.
- Service org: edp.buildth.ing/DevFW-CICD — public organization referenced for transparency.
- Service org: edp.buildth.ing/DevFW — private organization reference.
- (internal only) Repository (edp-doc): 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 — Forgejo project homepage.
- Upstream governance: Codeberg e.V. — referenced as steward/governance body.
- Upstream contribution: PR #9409 — GARM endpoints contribution.
- Upstream contribution: PR #9803 — webhook workflow events contribution.
- Upstream contribution: PR #9962 — ephemeral runners contribution.
- Upstream hosting: Codeberg.org — hosting platform used for upstream Forgejo contributions.