Components_Showcase/Open-Xchange_as_part_of_openDesk/Open-Xchange_as_part_of_openDesk_DE.md

@@ -11,7 +11,6 @@ Die OX App Suite, die 2005 ursprünglich als Open-Xchange Hosted Edition veröff
 
 - **Hochentwickelte E-Mail-Lösung**, die sowohl für private als auch für geschäftliche Nutzer:innen konzipiert ist und Funktionen wie die Verwaltung mehrerer Posteingänge, Delegation, E-Mail-Vorlagen und sogar den Einsatz von künstlicher Intelligenz bietet.
 - **Ein innovativer Kalender**, der die Bedürfnisse von privaten und geschäftlichen Nutzer:innen erfüllt und visuelles Terminmanagement, mehrere persönliche, gemeinsame und öffentliche Kalender, Zeitzonenmanagement, Ressourcenmanagement und Delegationsmöglichkeiten in sich vereint.
-- **Online-Speicher**, der mehr ist als nur ein Online-Dateispeicher. Er umfasst Drag & Drop auf dem Desktop, Miniatur- und Vollvorschau, Online-Bearbeitung von Dateien, Dateiversionierung und die Integration von Drittanbieterspeichern. Ein Highlight ist die E-Mail-Integration, sodass Benutzer:innen einfach Links anstelle von großen Anhängen senden können.
 - **Eine E-Mail- und Dateiverschlüsselung**, die die benutzerfreundlichste und sicherste Verschlüsselung überhaupt ist. Mit einem Mausklick können Benutzer:innen erst eine komplette E-Mail (E-Mail und Anhänge) verschlüsseln und danach das Profil transparent verschlüsseln. Eine Verschlüsselung, die funktioniert, weil sie so einfach ist.
 
 ![Screenshot aus der OX-Anwendung](../_media/OX%20App%20Suite%20as%20a%20product.png)

Development_Concept/openDesk-Entwicklungskonzept.md

+---
+pdf_footer: "Zusammenfassung openDesk Entwicklungskonzept"
+---
+
+# Zusammenfassung: Konzept für die Zusammenarbeit bei der Weiterentwicklung
+
+Dieses Dokument ist eine Zusammenfassung der Ausschreibungsunterlagen der Ausschreibung "*Rahmenvertrag über Weiterentwicklungs- und Supportleistungen für openDesk*". 
+
+Diese Struktur orientiert sich an den in der Ausschreibung definierten Bewertungskritieren.
+
+* [Konzept für die Projektsteuerung und den Personaleinsatz](./openDesk-Entwicklungskonzept_Konzept-Projektsteuerung-und-Personaleinsatz.md)
+* [Mind. drei Ideen und Konzepte zur Weiterentwicklung](./openDesk-Entwicklungskonzept_Ideen-und-Konzepte-Weiterentwicklung.md)
+* [Zusammenarbeit mit den Herstellern](./openDesk-Entwicklungskonzept_Zusammenarbeit-mit-Herstellern.md)
+* [Qualitätssicherungskonzept](./openDesk-Entwicklungskonzept_Qualitaetssicherungskonzept.md)
+
+## Executive Summary
+
+1. This project team will jointly develop openDesk with ZenDiS as a flagship project for Europe's digital sovereignty.
+
+2. The General Contractor (GC: B1 Systems) is bringing together the innovative power and development efforts of the involved open-source providers to create the world's best open-source communication and collaboration platform for public administration.
+
+3. Through upstream contributions, ZenDiS benefits from the developments and innovations of a global open-source community. B1 Systems and the participating open-source providers are unlocking this potential to ensure the sustainable and future-proof development of openDesk, based on the requirements defined by ZenDiS in its role as Product Owner of openDesk.
+
+## Memorandum of understanding: Key aspects of the collaboration
+
+1. Public money - Public Code. All roadmap sponsorhip by ZenDiS will be part of the Vendor's community editions. The Vendors are free to further develop enterprise features which are not released through their community editions.
+2. A key aspect of the openDesk project is to integrate the different modules for a superior user experience.
+3. The vendor's core business model is to provide enterprise subscriptions instead of providing development services (projects).
+4. General contractor provides upstream contributions to the main projects. If at all possible, the General Contractor does not support ZenDiS to fork the existing upstream projects and communities.
+5. The Vendors have to assure the quality of their releases like they already do as part of their SLA. This also includes the integration between modules which are not openDesk-specific. For openDesk-specific integrations the General Contractor does the integration testing. Here we strive to find synergies with upstream contributions to the test suite (open source).
+6. We strive for an international development community. The default project language in the project teams is English. ZenDiS can decide to have contracts and external communication and user documentation to be German (Amtssprache).
+7. ZenDiS leads the Product Owner Team of the openDesk product. The Vendors remain Product Owners of their products.
+8. The Vendors as the resource owners of the development capacities are members of the project steering committee (openDesk Community Board).
+9. We have continuous and regular releases of openDesk. Development of the different openDesk modules need to be independently releasable. Delays in one Vendor’s release must not block the openDesk releases.
+10. Decisions about the internal delivery processes remain with the Vendors. 
+11. ZenDiS is the final decision making authority for all openDesk projects. The Vendors decide about the roadmaps of their products. It is our goal to align the interests of all parties.
+12. We use openDesk and openCode for collaboration and management of the openDesk projects.
+13. We allow only professionals with the required skills and experience to work on the projects.
+14. We implement rolling forecasts and planning processes to level-out the required resources with the available capacities. The responsible parties avoid delays, peaks and interruptions on all planning levels. The GC and the Vendors are responsible, ZenDiS as project owner is accountable.
+15. ZenDiS decides on the delivery model (fixed price vs. agile).

Development_Concept/openDesk-Entwicklungskonzept_Glossar.md

+---
+pdf_footer: "Glossar openDesk Entwicklungskonzept"
+---
+
+# Glossar
+
+| Eintrag                                  | Bedeutung                                                    |
+| ---------------------------------------- | ------------------------------------------------------------ |
+| Angemessenes Entscheidungsgremium  (AGB) | In diesem Projekt übernimmt die Geschäftsführung des ZenDiS die Rolle des Angemessenen Entscheidungsgremiums.<br />Das angemessene Entscheidungsgremium (Appropriate Governance Body, AGB) ist die für die strategische Planung und das Portfoliomanagement zuständige Einheit. In Bezug auf openDesk Projekte ist es die Instanz, welche befugt ist, ein Projekt zu genehmigen, seinem erklärten Ziel zustimmen und die für die Umsetzung erforderlichen Mittel freizugeben.<br /> |
+| Arbeitspaket                             | Ein Arbeitspaket beschreibt einen Arbeitsauftrag, den ein Projektleiter an einen Teilprojektleiter bzw. Teamleiter übergibt. Die Beschreibung des Arbeitspaketes umfasst die zu erbringende Leistung, welche die beauftragte Person bzw. organisatorische Einheit (Team) erbringen soll sowie Angaben zum Zieltermin und den Zielkosten. |
+| Auftraggeber                             | Der Auftraggeber trägt die Gesamtverantwortung für das Projekt, Eigentümer des Business Case und Vorsitzender des Lenkungsausschusses.  Der Auftraggeber ist Eigentümer des Business Case.<br />In dieser Struktur ist mit Auftraggeber das ZenDiS gemeint und nicht der Generalunternehmer als Auftraggeber der Hersteller.<br />In dieser Rolle hat das ZenDiS als Auftraggeber bei allen Entscheidungen des Lenkungsausschuss ein Veto-Recht. |
+| Benutzervertreter                        | Der Benutzervertreter ist verantwortlich für die Spezifikation der Qualitätserwartungen des Kunden, die messbare Beschreibung der Ziele und des Nutzens. Gehört zum Endkunden.<br />Der Benutzervertreter ist Mitglied des Projektlenkungsausschuss. |
+| Gesamtprojektleiter                      | Projektmanager des Generalunternehmers                       |
+| Hersteller                               | Open Source Unternehmen, welche die Entwicklung der verwendeten openDesk-Module vorantreiben und hierzu Enterprise Subskriptionen anbieten. Die Hersteller übernehmen weiterhin als Maintainer die Wartung der Community Editions ihrer Software-Produkte. |
+| Endkunde                                 | Bezeichnet allgemein die Business-Ebene des Unternehmens und wird in Projekten durch Auftraggeber und Benutzervertreter repräsentiert. |
+| Lenkungsausschuss                        | Ein Gremium, bestehend aus den Interessensvertretungen des Projekts: Benutzer-, Lieferanten- und Auftraggeber-Interessen. Der Lenkungsausschuss ist dem Kunden gegenüber für das Projekt verantwortlich und den jeweiligen Ressourcen gegenüber weisungsbefugt (Ressourcen-Eigentümer). Auch PSC (Project Steering Committee). |
+| Lösungsanbieter                          | Mitglied des Lenkungsausschusses, verantwortlich für die Herstellung der Produkte, die technische Machbarkeit, die Qualität der Produkte und die Gewährleistung.<br />In diesem Fall sind sowohl die Hersteller als auch der Generalunternehmer Lösungsanbieter. |
+| Product Owner (ZenDiS)                   | Das ZenDiS definiert mit "Product Owner" seine Rolle als Auftraggeber bzw. Projekteigner, welcher die Leitlinien bei der Entwicklung der openDesk-Plattform vorgeben. Dies umfasst Aufgaben des Produkt- und Anforderungsmanagements.<br />In diesem Kontext ist nicht die Definition im Rahmen agiler Prozessmodelle, wie z. B. bei Scrum zu verstehen.<br />Siehe auch § 7 (1) des Rahmenvertrags. |
+| Product Owner                            | Rolle im Scrum Team. Typischerweise verantwortlich für das Management des Backlogs und die Interaktion mit dem Development Team. In modernen Umgebungen ist diese Rolle mittlerweile Teil der Arbeit eines Product Managers. Als eigenständige Rolle gibt es Product Owner heute hauptsächlich in Delivery Teams, die nach Wasserfall-Methode eine vorgegebene Aufgabe abarbeiten. Der Product Owner unterstützt dabei bestenfalls den Engineering Manager bei der Umsetzung, also beim _feasibility_-Risiko. |
+| Product Manager                          | Rolle in modernen Produkt Entwicklungs Teams. Zusammen mit dem Engineering Manager (verantwortlich für das _feasibility_-Risiko, d.h. gibt es eine vertretbare technische Lösung) und dem Design Manager (verantwortlich für das _usability_-Risiko, d.h. kann der Nutzer das Produkt leicht und einfach nutzen) verantwortet der Product Manager den Erfolg des Teams. In _Empowered Product Teams_ ist er dabei verantwortlich für das _value_-Risiko (wird der Kunde das Produkt kaufen, hat er eine Zahlungsbereitschaft, wird ein Nutzer-Bedürfnis adressiert) und das _business viability_-Risiko (ergibt das Produkt einen Sinn im gesamtwirtschaftlichen Kontext des Geschäfts inklusive der übergreifenden Strategie). Bei _Feature Teams_ hat der Product Manager diese Verantwortung nicht inne, sondern diese wird vom Auftraggeber und den Stakeholdern übernommen. Seine Verantwortung liegt hauptsächlich im Erreichen eines gewünschten Outputs/Features ohne dessen Erfolg zu verantworten. |
+| Produkt                                  | Ein Liefergegenstand, Input oder Output, materiell oder immateriell, der im Vorfeld beschrieben werden kann, hergestellt, qualitätsgeprüft und abgenommen wird. (TomL: Perhaps unimportant but this definition of Produkt reads more like an Arbeitspaket to me) (MRo: A product is a deliverable, the workpackage is the order to build one.) |
+| Projekt                                  | Eine temporäre Organisation zur Bereitstellung eines oder mehrerer Produkte im Rahmen der Kundenvorgaben. |
+| Teilprojektleiter                        | In diesem Kontext bezeicht Teilprojektleiter den Projektmanager bzw. Teammmanager seitens der Hersteller. Die Person, die für die Herstellung der Produkte, die vom Projektleiter (wie in einem Arbeitspaket/Arbeitsauftrag definiert), in angemessener Qualität, innerhalb eines angemessenen Zeitrahmens und zu Kosten, die für den Lenkungsausschuss akzeptabel sind. |
+| PMO                                      | Das Projekt Management Office (PMO) unterstützt den Gesamtprojektleiter bei den operativen und administrative Aufgaben des Gesamtprojektleiters und insbesondere bei der Erstellung der Projekt-Dokumentation und dem Projekt-Berichtswesen. |
+| Risikobearbeiter                         | Jemand, der eine Risiko-Maßnahme ausführt.                   |
+| Risikoeigentümer                         | Jemand, der ein Risiko während der Laufzeit beobachtet, berichtet, bei der Planung von Maßnahmen hilft und Maßnahmen einleitet. |
+|                                          |                                                              |

Development_Concept/openDesk-Entwicklungskonzept_Qualitaetssicherungskonzept.md

+---
+pdf_footer: "openDesk Qualitätssicherungskonzept"
+---
+
+## Qualitätssicherungskonzept
+
+## Grundsätzliches
+
+In diesem Dokument wird das Qualitätssicherheitskonzept für openDesk beschrieben. Bei openDesk handelt es sich um eine Software, die aus Komponenten mehrerer Hersteller zusammen gestellt wird. Jede Komponente der beteiligten Hersteller unterliegt für sich bereits einem Qualitätssicherungskonzept, mit dem die Qualität des jeweiligen Softwareproduktes sicher gestellt wird. 
+Dieses übergreifende Konzept zielt dabei auf die gemeinsame Funktionsweise des Gesamtprodukts mit dem Fokus auf das Interagieren der einzelnen Bestandteile miteinander, um so auch diesen Aspekt auf ein höchstmögliches Qualitätsniveau heben zu können.
+
+Die Komponenten von openDesk können in der Zukunft auch austauschbar und erweiterbar sein. Das hier dargestellte Qualitätssicherheitskonzept berücksichtigt dies und bindet die Qualitätssicherung der beteiligten Hersteller modular ein. Jeder beteiligte Hersteller an openDesk ist verpflichtet dieses Qualitätssicherungskonzept zu unterstützen. Bei der Auswahl zukünftiger Hersteller sollte dies als Kriterium bei der Auswahl berücksichtigt werden, damit die Gesamtqualität von openDesk gewährleistet bleibt.
+
+Im Abschnitt "Umfang der Qualitätssicherung" wird die Unterscheidung dieser aufeinander aufbauenden Qualitätssicherungen näher erläutert.
+
+Für die vom ZenDiS beauftragten Anforderungen werden Testfälle durch das QS-Team des Generalunternehmers erstellt und mit den Herstellern abgestimmt.
+
+Die Testabdeckung wird über dokumentierte Testfälle festgelegt. Details zur Testabdeckung werden ebenfalls im Abschnitt "Umfang der Qualitätssicherung" beschrieben.
+
+Im Abschnitt "Umfang der Qualitätssicherung" wird darüber hinaus festgelegt, welche Testtypen in der Qualitätssicherung von openDesk angewendet werden.
+
+Testergebnisse im Rahmen der Qualitätssicherung von openDesk sind grundsätzlich schriftlich zu dokumentieren. Diese schriftliche Dokumentation ist Basis für die jeweilige Freigabe eines Releases. Die Details der Dokumentation werden im Abschnitt "Dokumentation von Testergebnissen" beschrieben.
+
+Die Hersteller der bereitgestellten Software Module streben innerhalb ihres Qualitätssicherheitsprozesses eine größtmögliche Abdeckung mit automatisierten Tests an. Das QS-Team der Generalunternehmers stellt sicher, dass modulübergreifende Tests abgedeckt sind, wenn diese im Rahmen der Beauftragung notwendig sind.
+
+Im Abschnitt "Fehlerkategorien" wird definiert, welche Fehlerkategorien es bei openDesk gibt. Diese Fehlerkategorien legen die Basis für die darauf aufbauende Durchführung von Tests.
+
+Der Ablauf der Qualitätssicherung ist im Abschnitt "Durchführung der Tests" näher erläutert.
+
+Der Abschnitt "Voraussetzungen für das Testen" beschreibt abschließend die Bedingungen, die von den beteiligten Parteien erfüllt sein müssen, damit dieses Testkonzept erfüllt werden kann.
+
+## Umfang der Qualitätssicherung
+
+Die Qualitätssicherung der Herstellermodule erfolgt in der Verantwortung der jeweiligen Hersteller, im Rahmen der Qualitätssicherung der Upstream-Entwicklung des jeweiligen Moduls.
+Speziell für openDesk beinhaltet diese Qualitätssicherung explizit auch die Funktionen, die für openDesk vereinbart und entwickelt werden. openDesk Implementierungen unterliegen damit den selben strengen Qualitätskriterien der jeweiligen Herstellermodule. Abweichungen von diesen Qualitätskriterien - wie etwa das Bereitstellen eines Pre-Releases für openDesk - bedürfen der beiderseitigen Vereinbarung zwischen ZenDiS und dem jeweiligen Hersteller.
+
+Für den Fall, dass sich openDesk Funktionen bei der Implementierung auf mehrere Herstellermodule auswirken, verpflichten sich die Hersteller mit der Vereinbarung zur Umsetzung der Funktion, dass sie in den betroffenen Module auch für diese modulübergreifenden Funktionen die Qualität sicherstellen.
+
+Auf diese Weise qualitätsgesicherte Module werden durch die Hersteller in der Integrationsumgebung für openDesk bereit gestellt. Die Hersteller stellen sicher, dass ihre Module in der Integrationsumgebung lauffähig und funktional sind.
+
+Ab diesem Punkt beginnt die Verantwortung des QS-Team (Generalunternehmer). Das QS-Team (Generalunternehmer) 
+prüft hier die im Projekt vereinbarten Funktionen und führt die Abnahme auf einer dafür geeigneten Testumgebung durch. Der Abnahmetest prüft den Funktionsumfang auf Basis der zuvor vereinbarten Anforderungen.
+
+Die folgenden Abschnitte beziehen sich ausschließlich auf den hier beschriebenen Abnahmeprozess durch das Product Owner Team (ZenDiS).
+
+Der Abnahmetest umfasst folgende Testarten:
+
+* Funktionaler Test
+* Usability Test
+
+Die funktionalen Tests stellen sicher, dass die vereinbarten Anforderungen in der ausgelieferten Software erfüllt sind, und die Funktionalität vollständig einsetzbar ist.
+Die Usability Tests stellen sicher, dass die Software den vereinbarten Anforderungen an Usability, wie z.B. übergreifende openDesk Navigation, Anforderungen an Barrierefreiheit, Nutzbarkeit des Nutzerinterfaces gegeben sind.
+
+Last- und Performance-Tests werden unabhängig vom Abnahmetest in dem dafür vorgesehenen Leistungsbaustein W.1.4 vereinbart und durchgeführt.
+
+Sicherheitstests werden unabhängig vom Abnahmetest in dem dafür vorgesehenen Leistungsbaustein W.5.3 vereinbart und durchgeführt.
+
+## Dokumentation von Testergebnissen
+
+Zur Nachvollziehbarkeit werden Testergebnisse in einem dafür vereinbarten Prozess dokumentiert. 
+Die Dokumentation der Testergebnisse muss Folgendes beinhalten:
+
+* Ausführliche Beschreibung des Fehlverhaltens
+* Schrittweises Vorgehen des Test zur Reproduktion des Fehlverhaltens
+* Angabe der Umgebung, in der das Fehlverhalten beobachtet wurde
+* Angabe der Version der getesteten Software
+* Datum und Uhrzeit des Tests
+* Angabe des Nutzerzugangs, mit dem der Test durchgeführt worden ist.
+* Version des verwendeten Web-Browsers sowie Betriebssystem 
+* Referenz zur Anforderung, die nicht erfüllt worden ist.
+* Eine Einschätzung der Schwere der Funktionsabweichung im Sinne der im Folgenden Abschnitt definierten Fehlerkategorien.
+
+Das QS-Team erstellt für die gefundenen Fehler Fehlerberichte. Sofern der Fehler einem Modul zugeordnet werden kann, erfolgt der Fehlerbericht gemäß der Contribution Richtlinien der jeweiligen Upstream Projekte (siehe Abschnitt "Zusammenarbeit mit Herstellern").
+
+Ist eine solche Zuordnung durch das QS-Team nicht möglich, wird der Fehlerbericht im entsprechenden Repository auf Open CoDE erfasst.
+
+> [!IMPORTANT]
+>
+> Bei der Erstellung von Fehlerberichten ist die Erstellung von Duplikaten zu vermeiden.
+
+## Fehlerkategorien
+
+Für die Bewertung der Auswirkung von Fehlern werden Fehlerkategorien vereinbart. Anhand der Fehlerkategorien können die beteiligten Parteien ein einheitliches, abgestimmtes Vorgehen festlegen, mit welcher Priorität die Behebung von Fehlern erfolgen soll.
+Die Fehlerkategorien, werden insbesondere im Abnahmeprozess herangezogen.
+
+**Blocker**
+
+Ein Fehler der Kategorie *Blocker* ist so schwerwiegend, dass eine Kernfunktion von openDesk nicht nutzbar ist, oder eine große Zahl von Nutzenden in der Bedienung der Software stark eingeschränkt ist. Fehler dieser Kategorie sind releaseverhindernd. Der Auftragnehmer ist verpflichtet schnellstmöglich eine Behebung für den Fehler bereit zu stellen. 
+
+**Schwerer Fehler**
+
+Ein Fehler der Kategorie *schwerer Fehler* ist eine deutliche Einschränkung der Nutzbarkeit der Software. Die Software kann aber weiter genutzt werden oder der Fehler durch einen akzeptablen Workaround umgangen werden. Fehler dieser Kategorie sind nicht releaseverhindernd. Der Auftragnehmer ist jedoch verpflichtet schnellstmöglich ein Patch-Release für die Behebung bereit zustellen.
+
+**Kleiner Fehler**
+
+Ein Fehler der Kategorie *kleiner Fehler* ist ein Abweichung der Software von der vereinbarten Anforderung, der die Nutzung kaum oder nur in besonderen Situationen beeinträchtigt. 
+Fehlerbehebungen dieser Kategorie werden im Rahmen des üblichen Releaseprozesses, mit einem zukünftigem Release behoben.
+
+## Testdurchführung
+
+Der Abnahmetest erfolgt umgehend nach Bereitstellung der Software auf dem dafür vereinbarten Testsystem. Möglicherweise entdeckte Fehler werden dem Auftragnehmer und dem betroffenen Hersteller umgehend nach Abschluss des Testlaufs zur Kenntnis gegeben. Fehlerbeschreibungen werden explizit nicht bis zur vollständigen Durchführung der Tests zurückgehalten. Auf diese Weise wird dem Auftragnehmer die Möglichkeit gegeben, eine Fehlerkorrektur schnellstmöglich bereit zustellen.
+
+Der Auftragnehmer hat die Möglichkeit den Auftraggeber im Vorwege des Abnahmetests um einen Vorabtest zu bitten. Dies sollte insbesondere dann erfolgen, wenn weitreichende Veränderungen der Software in einer Lieferung erwartet werden. Auf diese Weise soll eine mögliche Abweichung von Anforderungen frühzeitig bemerkt werden. Der Zeitraum für mögliche Nachbesserungen wird auf diese Weise erweitert. (Fail-Fast-Prinzip)
+Die Testumgebung für solche Vorabtests wird durch den Generalunternehmer bzw. den Hersteller der Software bereit gestellt.
+
+Die Ergebnisse des Abnahmetests und insbesondere die Bewertung der Fehler sind die Ausgangsbasis für die Abnahme der Software im Sinne der zuvor vereinbarten Anforderung. Die Abnahmeerklärung beinhaltet dabei sowohl die Abnahme im Sinne der Projektvereinbarung, als auch die Auswirkung auf die Releasebereitstellung. 
+
+Die Inbetriebnahme einer Funktion ist grundsätzlich die implizite Abnahme der bereitgestellten Funktionalität. Eine Abnahme kann auch unter dem Vorbehalt der Nachbesserung dokumentierter Fehler erfolgen. In diesem Fall ist die Inbetriebnahme keine implizite Abnahme der bereitgestellten Funktionalität.
+
+## Voraussetzungen für das Testen
+
+Für die erfolgreiche Durchführung der Abnahmetests sind folgende Voraussetzngen zu erfüllen:
+* Eine geeignete Testumgebung steht zur Verfügung.
+* Es wird die von den Herstellern bereitgestellte Software in der dafür vorgesehenen Version eingesetzt.
+* Die Hersteller haben im Vorwege ihre Software gemäß ihrer Qualitätsvorgaben für ihre Software durchlaufen. Der Hersteller garantiert mit der Auslieferung, dass die Software die Qualitätskriterien des Herstellers erfolgreich bestanden hat.
+* Der Abnahmetest basiert auf den gemeinsam vereinbarten Anforderungen. Diese Anforderungen sind zwischen der ZeDiS, dem Generalunternehmer und den  beteiligten Herstellern im Rahmen der Einzelbeauftragungen vor Implementierungsbeginn zu vereinbaren.
+* Der Abnahmetest deckt die vereinbarten Anforderungen der zu testende Auslieferung vollumfänglich ab.
+* Das eingesetzte Personal für die Testdurchführung besitzt ausreichend Erfahrung in der openDesk Funktionalität, dem vereinbarten Testprozess für openDesk und Qualitätssicherung von Software im allgemeinen.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

README.md

 [Please find the English version here](./README_EN.md)
 
-**Inhalte / Schnellnavigation**
+# Die Office und Collaboration Suite für die Öffentliche Verwaltung
 
-[[_TOC_]]
+Von überall aus gemeinsam mit Kolleg:innen an einem Dokument arbeiten, ohne ständig E-Mails hin und her zu schicken. Sich spontan in einer Videokonferenz zu offenen Fragen abstimmen und schnell zu einer Entscheidung kommen. Projekte team- und ressortübergreifend effizient managen oder das Wissen Einzelner allen zugänglich machen.
 
-# openDesk
+Ob bei der mobilen Arbeit zu Hause oder vom Schreibtisch aus dem Büro: Mit der Office & Collaboration Suite openDesk eröffnen sich für die Mitarbeiter:innen in Ämtern und Behörden diese und tausend weitere Möglichkeiten, ihre Arbeit und Zusammenarbeit neu zu gestalten und Prozesse effizienter zu steuern.
 
-openDesk ist wesentlicher Bestandteil für eine selbstbestimmte, sichere und zukunftsfähige Informationstechnik (IT) für die gesamte Öffentliche Verwaltung (ÖV). Dank openDesk wird Mitarbeitenden, IT-Administratoren und Betreibern der ÖV zukünftig eine **wirksame Open Source (OS)-basierte Alternative im Bereich Arbeitsplatzumgebung** zur Verfügung gestellt. Die Arbeitsplatzsuite stellt dabei eine Maßnahme im Rahmen der **gemeinsamen Strategie zur Stärkung der Digitalen Souveränität von Bund, Ländern und Kommunen** sowie einen wesentlichen Schritt zur Auflösung kritischer Abhängigkeiten in der IT der ÖV dar.
+## Drei gute Gründe für openDesk
 
-Weiterführende Informationen können in unseren [FAQs](./FAQ.md) nachgelesen werden.
+### 1. Kollaboration
 
-## Projektübersicht
+openDesk ermöglicht eine effektive digitale Zusammenarbeit in der Öffentlichen Verwaltung: Erstellen von Projekten, gemeinsames Arbeiten an Dokumenten, Wiki, Chat, Videokonferenz und vieles mehr – alles aus einer Hand.
 
-Das Projekt "openDesk - Der Souveräne Arbeitsplatz" basiert auf dem Auftrag des IT-Rats an das Bundesministerium des Innern und für Heimat (BMI) zur Erarbeitung und Prüfung einer Alternative im Bereich Arbeitsplatzsoftware für die ÖV vom Oktober 2020.
+### 2. Bedarfsgerechtigkeit
 
-Die Erarbeitung von openDesk erfolgt durch eine **kollaborative, offene und effektive Zusammenarbeit innerhalb der ÖV gemeinsam mit dem OS-Ökosystem**. Mitte 2022 ist die Beauftragung des IT-Dienstleisters Dataport für die operative Entwicklung von openDesk gestartet. Über die Projektstrukturen sind die OS-Hersteller der genutzten OS-Softwareprodukte (u.a. Produktstrategieboard), weitere IT-Dienstleister und Teilnehmende aus der ÖV (u.a. Architekturboard) sowie weitere Behörden zur Erprobung und Unterstützung der nutzerzentrierten Entwicklung von openDesk (u.a. User Experience Board) direkt beteiligt.
+openDesk ist eine bedarfsgerechte Lösung für die digitale Zusammenarbeit in der Öffentlichen Verwaltung:
+Die Software wurde auf diese spezifischen Anforderungen und Bedürfnisse zugeschnitten.
 
-### Ausgangslage
+### 3. Souveränität und Sicherheit
 
-In der Informationstechnik (IT) der ÖV bestehen in einigen Bereichen hohe – zum Teil kritische – Abhängigkeiten von einzelnen Technologieanbietern. Dies kann zu Schmerzpunkten wie z.B. eingeschränkter Informationssicherheit, begrenzter Flexibilität oder fremdgesteuerten Innovationen führen und die Digitale Souveränität der ÖV sowie die staatliche Handlungsfähigkeit einschränken bzw. beeinflussen. Zunehmende Abhängigkeiten bergen für die ÖV die Gefahr, die Kontrolle über die eigene IT und damit letztendlich auch die Fähigkeit zum souveränen Handeln zu verlieren.
+Als Open-Source-Software stärkt openDesk die Digitale Souveränität durch volle Transparenz und Kontrolle über den Quellcode. Zudem sorgt diese Off enheit für hohe Sicherheit, da Sicherheitslücken schnell erkannt und behoben werden können. Daten und Prozesse bleiben dadurch zuverlässig geschützt.
 
-In einer gemeinsamen Strategie zur Stärkung der Digitalen Souveränität der ÖV haben **Bund, Länder und Kommunen die Förderung und den verstärkten Einsatz von alternativen – Open-Source-basierten – IT-Lösungen beschlossen**.
+## Integration von leistungsstarken Anwendungen
 
-_Open Source (OS)_ ist dabei ein Lizenzmodell, das Nachnutzenden und Anwendenden der Software das Recht der **Einsehbarkeit, Weiterverbreitung und Modifikation** der jeweiligen Komponenten einräumt.
+openDesk integriert eine Reihe von leistungsstarken Open-Source Anwendungen unter einer Oberfläche. Für die kollaborative Arbeit in der Öffentlichen Verwaltung ergeben sich damit zahlreiche Einsatzmöglichkeiten.
 
-### Erfolge
-
-Mit dem ersten Quartal 2024 ist der Aufbau der Basisvariante von openDesk erfolgt. Die Basisfunktionen umfassen alle notwendigen Anwendungen für die Mitarbeitenden der ÖV in den Bereichen **Produktivität, Kollaboration und Kommunikation**. Alle Anwendungen basieren auf bestehenden und bewährten OS-Produkten.
-
-Die Projektphase 2023 unterteilte sich grob in die **technische Entwicklung** (z.B. Architektur, Plattform- und Anwendungsdienste), die **Einbettung in die Strukturen der ÖV** (z.B. Deutsche Verwaltungscloud-Strategie (DVS)-konforme Bereitstellung) und die **nutzerzentrierte Erprobung der Anwendungen des Betriebs** und der **perspektivischen Einbindung von Fachverfahren**.
-
-Im ersten Quartal 2024 übergibt das BMI die Trägerschaft von openDesk – Der Souveräne Arbeitsplatz an das Zentrum Digitale Souveränität (ZenDiS). Das BMI wird dabei weiterhin als Auftraggeber und zentraler Stakeholder bei der Weiterentwicklung von openDesk agieren.
-
-## Produktvision
-
-![openDesk image](./Images/openDesk_Vision_DE.png)
-
-openDesk ist eine nutzerfreundliche und integrierte Komplettlösung mit allen notwendigen Anwendungen (inkl. Fachverfahren) für die Mitarbeitenden der ÖV. Hierzu gehören insbesondere Anwendungen aus den folgenden Bereichen:
-
-- **Produktivität:** Textverarbeitung, Tabellenkalkulation, Erstellung von Präsentationen
-- **Kollaboration:** Gemeinsames Bearbeiten von geteilten Dateien, Wissensmanagement, Visualisierung, Projektmanagement
-- **Kommunikation:** Durchführung von Video- und Audiokonferenzen, Nutzung von E-Mail und Kurznachrichtendiensten sowie Terminorganisation über elektronische Kalender
-- **Übergreifend:** Anbindung ausgewählter Fachverfahren (z.B. E-Akte)
-
-Als Gesamtlösung sind die Anwendungen und Funktionen von openDesk über ein zentrales Portal zugänglich, das alle Einzelprodukte vereint.
-**Die Bestandteile und zugrundeliegende Architektur von openDesk bilden eine souveräne IT-Lösung.**
-Zu diesem Zweck werden folgende Eigenschaften der einzelnen Komponenten und der gewählten Architektur sichergestellt:
-
-- **Modularität:** Behörden können spezifisch entscheiden, bereits vorhandene Lösungen in openDesk zu integrieren oder auf ein Modul von openDesk zu verzichten
-- **Austauschbarkeit:** Produkte können im Zuge der (Weiter-)Entwicklung flexibel ausgetauscht werden ohne Beeinträchtigung der Gesamtfunktionalität und bei Einhaltung der Architekturgrundlagen
-- **Interoperabilität:** Der openDesk wird in einer heterogenen Softwarelandschaft einsetzbar sein, z.B. durch die Anbindung an bestehende (Fach-)Anwendungen durch Schnittstellen und APIs
-
-**Der openDesk wird in einer transparenten, betreiberunabhängigen und portablen Form zur Verfügung gestellt.**
-
-- **Containerisierung:** Die Container der Komponenten des openDesk entsprechen den Richtlinien und Vorgaben der Deutschen Verwaltungscloud-Strategie (DVS) und können damit in jedem (DVS-) Rechenzentrum der ÖV eingesetzt werden.
-- **Bereitstellung auf Open CoDE:** Die (Weiter-)Entwicklung von openDesk erfolgt als Open Source und die Komponenten werden kontinuierlich auf dem öffentlich zugänglichen Open CoDE Repository der Öffentlichen Verwaltung bereitgestellt.
-
-## Basisvariante
-
-Die Erarbeitung von openDesk setzt auf der Dataport-Lösung dPhoenixSuite auf, die bereits seit März 2021 in Form von Proof-of-Concepts (PoCs) beim Bund erprobt wird (u.a. mit dem Robert Koch-Institut, Bundesamt für Seeschifffahrt und Hydrographie, Bundesministerium für Digitales und Verkehr, Bundesministerium des Innern und für Heimat).
-
-Die in der dPhoenixSuite integrierten OS-Komponenten (z. B. Nextcloud, Collabora, Open-Xchange oder Element/Jitsi sowie die Identitätsmanagement-Lösung und das Portal von Univention) wurden im Rahmen der Weiterentwicklung zu openDesk um weitere Funktionen ergänzt. Darüber hinaus wurde openDesk mit zusätzlichen OS-Komponenten ausgestattet.
-
-Eine Übersicht sämtlicher OS-Komponenten für die Basisvariante ist in folgender Übersicht dargestellt.
+Eine Übersicht sämtlicher Anwendungen ist in folgender Übersicht dargestellt.
 
 ![openDesk image](./Images/openDesk_Komponenten.png)
 
 Einen technischeren Überblick gibt unsere [OVERVIEW](./OVERVIEW.md).
 
-![ShowcaseVideo openDesk](./Images/OpenDesk_Screencast_01-24-v3.mp4){width=100%}
-
-Außerdem wurde ein Informationsvideo erstellt, das einen ersten Eindruck zu openDesk und seinen Funktionen in der Basisvariante vermittelt.
+Außerdem wurde ein Informationsvideo erstellt, das einen ersten Eindruck zu openDesk und seinen Funktionen vermittelt.
 
-Neben der technischen Entwicklung ist die Einbettung in die Strukturen der ÖV ein wesentlicher Bestandteil der Erarbeitung von openDesk. Dies beinhaltet u.a., dass eine Integration relevanter Fachverfahren (z.B. e-Akte) von Beginn an mitgedacht wird. Weiterhin orientiert sich die Entwicklung von openDesk maßgeblich an den Anforderungen des Bundesclients.
-Parallel zur technischen Entwicklung wurden die Anwendungen und Funktionen von Beginn an von ausgewählten Testpartnern aus der ÖV (u.a. RKI, BSH, BMDV, BMI, etc.) im Rahmen einer Nutzerforschung erprobt.
+![Einführung openDesk](.opencode/screenshots/openDesk_Intro.mp4){width=100%}
 
 ## Rückmeldungen und Beteiligung
 

README_EN.md

-**Content / quick navigation**
+# The office and collaboration suite for the public administration
 
-[[_TOC_]]
+Work together with colleagues on a document from anywhere without constantly sending emails back and forth. Spontaneously coordinate open questions in a video conference and come to a decision quickly. Efficiently manage projects across teams and departments or make the knowledge of individuals accessible to everyone.
 
-# openDesk
+Whether working remotely at home or from your desk in the office: the Office & Collaboration Suite openDesk opens up these and a thousand other possibilities for employees in offices and authorities to redesign their work and collaboration and manage processes more efficiently.
 
-openDesk is an essential component for self-determined, secure and future-proof information technology (IT) for the entire German public administration. In the future, openDesk will provide an **effective open source (OS) based alternative in the workspace environment** for employees, IT administrators and operators engaged in the field of public administration. The suite is a measure within the framework of the **joint strategy to strengthen the digital sovereignty of the federal, state and local governments** and represents a significant step towards resolving critical dependencies in the IT of public administration. Further information can be found in our [FAQs](./FAQ.md) (currently German only).
+## Three good reasons for openDesk
 
-## Project overview
+### 1. Collaboration
 
-The project "openDesk – the sovereign workplace" is based on the IT Council's mandate to the Federal Ministry of the Interior and Community (BMI) to develop and test an alternative in the field of workplace software for the German public administration from October 2020.
+openDesk enables effective digital collaboration in the public administration: creating projects, working together on documents, wiki, chat, video conferencing and much more - all from a single source.
 
-openDesk is being developed through **collaborative, open and effective cooperation within the public administration and the OS ecosystem**. The commissioning of the IT service provider Dataport for the operational development of openDesk started mid-2022. Due to the prevailing project structures, OS developers of the software used (e.g. product strategy board), other IT service providers and participants from the public administration sector (e.g. architecture board) as well as other authorities for testing and supporting the user-centered development of openDesk (e.g. user experience board) are directly involved.
+### 2. Oriented to the needs of the public administration
 
-### Initial situation
+openDesk is a demand-oriented solution for digital collaboration in the public administration: The software has been tailored to these specific requirements and needs.
 
-In some areas of public administration information technology (IT), there is a high - sometimes critical - dependency on individual technology providers. This can lead to pain points such as limited information security, limited flexibility or externally controlled innovations and restrict or influence the digital sovereignty of public administration and the state's ability to act. Increasing dependencies therefore entail the risk for public administration of losing control over their own IT and ultimately the ability to act with sovereignty.
+### 3. Sovereignty and security
 
-In a joint strategy to strengthen the digital sovereignty of public administration, **the federal government, federal states and local authorities have decided to promote and increase the use of alternative – OS-based – IT solutions**.
+As open source software, openDesk strengthens digital sovereignty through full transparency and control over the source code. This openness also ensures a high level of security, as security gaps can be quickly identified and remedied. Data and processes are therefore reliably protected.
 
-_Open source (OS)_ is a license model that grants users and operators of the software the right to **view, redistribute and modify** the respective components.
+## Integration of powerful applications
 
-### Achievements
+openDesk integrates a range of powerful open source applications under one interface. This opens up numerous application possibilities for collaborative work in public administration.
 
-The basic version of openDesk will be completed by the first quarter of 2024. The basic functions include all the necessary applications for public administration employees in the areas of **productivity, collaboration and communication**.
-All applications are based on existing and proven OS products.
-
-The 2023 project phase was roughly divided into **technical development** (e.g. architecture, platform and application services), **embedding in the structures of the German public administration** (e.g. German Administration Cloud Strategy (DVS)-compliant provision) and **user-centered testing of the application's operation** and the **prospective integration of special applications** (Fachanwendungen).
-
-From the first quarter 2024, the BMI will hand over the sponsorship of _openDesk – The Sovereign Workplace_ to the Center for Digital Sovereignty (ZenDiS). The BMI will continue to act as the client and central stakeholder in the further development of openDesk.
-
-## Product vision
-
-![openDesk image](./Images/openDesk_Vision_EN.png)
-
-openDesk is a user-friendly and integrated full solution with all necessary applications (including special applications) for public administration employees.
-In particular, this includes applications from the following areas:
-
--	**Productivity:** word processing, spreadsheets, creating presentations
--	**Collaboration:** joint editing of shared files, knowledge management, visualization tool, project management
--	**Communication:** conducting video and audio conferences, using e-mail and short message services as well as organizing appointments via electronic calendars
--	**Comprehensive:** Connection of selected special applications (e.g. e-file)
-
-As a complete solution, the applications and functions of openDesk are accessible via a central portal that combines all individual products.
-
-**The components and underlying architecture of openDesk form a sovereign IT solution.**
-For this purpose, the following properties of the individual components and the selected architecture are ensured:
-
--	**Modularity:** Authorities can specifically decide to integrate existing solutions into openDesk or do without an openDesk module
--	**Interchangeability:** Products can be exchanged flexibly in the course of (further) development without impairing the overall functionality and in compliance with the architectural principles
--	**Interoperability:** openDesk can be used in a heterogeneous software landscape, e.g. by connecting to existing (special) applications via interfaces and APIs
-
-**openDesk is provided in a transparent, operator-independent and portable form:**
-
--	**Containerization:** The containers of openDesk components comply with the guidelines and specifications of the German Administration Cloud Strategy (DVS) and can therefore be used in any (DVS) data center of the German public administration
--	**Provision on Open CoDE:** (Further) development of openDesk is carried out as OS and all components are continuously provided on the publicly accessible Open CoDE Repository of the public administration
-
-## Basic version
-
-The development of openDesk is based on the Dataport solution dPhoenixSuite, which is already being tested since March 2021 in the form of proof-of-concepts (PoCs) at the federal level (including Robert Koch Institute, Federal Maritime and Hydrographic Agency, Federal Ministry for Digital and Transport, Federal Ministry of the Interior and Community, amongst others).
-
-The OS components integrated in the dPhoenixSuite (e.g. Nextcloud, Collabora, Open-Xchange or Element/Jitsi as well as the identity management solution and the portal from Univention) were supplemented with additional functions as part of the further development of openDesk. Furthermore, openDesk was equipped with additional OS components.
-
-An overview of all OS components for the basic version is shown below:
+An overview of all applications is shown in the following overview.
 
 ![openDesk image](./Images/openDesk_Komponenten_EN.png)
 
 Our [OVERVIEW](./OVERVIEW.md) provides further (technical) insights (currently German only).
 
-In addition to technical development, **embedding openDesk in the structures of the public administration system** is an essential part of the development of openDesk. This means, among other things, that the integration of relevant **special applications** (e.g. e-file) is considered right from the start. Furthermore, the development of openDesk is largely based on the **requirements of the federal client**.
-
-Parallel to the technical development, the applications and functions were tested from the outset by selected test partners from the public administration sector (e.g. RKI, BSH, BMDV, BMI, etc.) as part of user research.
-
 ## Feedback and participation
 
 openDesk is being continuously developed, which is why we welcome suggestions for improvement and feedback.