DevFW-CICD/website-and-documentation
23
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
website-and-documentation/content/en/docs/governance/compliance-audit/_index.md

7.3 KiB
Raw Blame History

title linkTitle weight description
Compliance & audit Compliance 30 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 our custom extensions (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

We actively contributed our extensions back to the upstream Forgejo project on Codeberg.org.

Key Pull Requests:

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

What we learned / decided (PII-free synthesis)

The workshop and research artifacts consistently point to a few pragmatic decisions and product learnings (summarized here without personal data1):

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

  1. PII = “personally identifiable information”. “PII-free synthesis” means we summarize patterns, decisions, and learnings without including names, participant lists, direct quotes, or other details that could identify individuals. ↩︎