88 lines
7.4 KiB
Markdown
88 lines
7.4 KiB
Markdown
---
|
|
title: "Compliance & audit"
|
|
linkTitle: "Compliance"
|
|
weight: 30
|
|
description: >
|
|
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)](/docs/edp/forgejo/). It is hosted at **[edp.buildth.ing](https://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](https://forgejo.org/)** as the core self-hosted Git service was driven by specific strategic requirements:
|
|
|
|
- **EU-Based Stewardship:** Forgejo is stewarded by **[Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/)**, 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`](https://edp.buildth.ing/DevFW-CICD) organization is publicly accessible, fostering transparency.
|
|
- **Private Access:** Sensitive development occurs in restricted organizations (e.g., [`DEVFW`](https://edp.buildth.ing/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](https://codeberg.org/)**.
|
|
|
|
**Key Pull Requests:**
|
|
|
|
- **API Compatibility:** Added GitHub-compatible endpoints for runner registration.
|
|
- [PR #9409: Feat: Add endpoints for GARM](https://codeberg.org/forgejo/forgejo/pulls/9409)
|
|
- **Webhook Support:** Implemented webhook triggers for workflow events.
|
|
- [PR #9803: Feat: Add webhook support for workflow events](https://codeberg.org/forgejo/forgejo/pulls/9803)
|
|
- **Ephemeral Runners:** Added support for runners that terminate after a single job.
|
|
- [PR #9962: Feat: Support for ephemeral runners](https://codeberg.org/forgejo/forgejo/pulls/9962)
|
|
|
|
## 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](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902567168/eDF+Stakeholder+Workshops) (internal/external workshops, goals, and intended outcomes).
|
|
- A concrete external workshop session is documented in Confluence: [external stakeholder workshop](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/936478033/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.](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/915155061/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[^pii-free]):
|
|
|
|
- **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).
|
|
|
|
[^pii-free]: PII = “personally identifiable information”. “PII-free synthesis” means summarizing patterns, decisions, and learnings without including names, participant lists, direct quotes, or other details that could identify individuals.
|
|
|
|
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:
|
|
|
|
- Work package definition and objectives: [Workpackage e.3 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704046/Workpackage+e.3+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers)
|
|
- Deliverable (incl. PoC results summary around autonomous UI/UX testing and “happy path” user flows): [Deliverable D66 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704082/Deliverable+D66+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers)
|
|
|
|
See also: the central [References](/docs/governance/references/) index.
|