registrystack / registrystack/registry-stack

Complete one independent deployment pilot before Registry Stack 1.0

Offen
#358 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
1.0-blocker area:docs area:notary area:registryctl area:relay criticality:p2 triage:needs-implementation
Vorherrschende Sprache
Rust
Sterne
2
Forks
0
Ø Merge
2 Std. 55 Min.
Gemergte PRs (30 T.)
130

Beschreibung

## Context

Automated tests and maintainer-run demonstrations do not prove that an external operator can configure and run the frozen product. Before 1.0, at least one named integration should reach the externally piloted evidence level: an operator outside the Registry Stack implementation team configures and runs the post-convergence release candidate and the resulting findings are triaged.

This is an adoption and operability gate, not a request to expose a country's private deployment or data.

## Scope

- Select one maintained, pinned integration profile and an external operator or partner able to run it independently.
- Use a post-convergence 1.0 release candidate and only the documentation and release artifacts intended for adopters.
- Have the external operator install or deploy the supported topology, author or adapt the Registry project, configure environment bindings, run offline checks, and execute the documented end-to-end journey.
- Exercise Relay consultation and, where the selected journey includes Notary, the consultation-backed claim or credential flow.
- Record usability, configuration, diagnostics, upgrade, operational, security-boundary, and documentation findings.
- Triage every finding as fixed before 1.0, an explicitly accepted limitation, or evidence that the support claim must be narrowed.

## Acceptance criteria

- An external operator completes the frozen profile without implementation-team members silently editing generated artifacts or taking over the deployment.
- The exact release candidate, integration version and operation, supported topology, and journey are recorded.
- The operator can diagnose ordinary configuration and source failures using shipped commands and documentation.
- No credentials, personal data, private endpoints, or confidential deployment details appear in GitHub evidence.
- Blocking findings are resolved and verified; accepted limitations are reflected in the public support wording and operator guidance.
- A concise public, redacted pilot report links the resulting issues and states exactly what the pilot did and did not prove.

## Non-goals

- Product-official endorsement by the upstream OpenCRVS, DHIS2, or OpenSPP project.
- Publishing country data or deployment secrets.
- Claiming broad production readiness from one pilot.

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

Beginne damit, ein gepflegtes, festgelegtes Integrationsprofil, einen externen Operator und den 1.0 Release Candidate nach der Konvergenz für einen Pilotversuch zu identifizieren. Folge der dokumentierten Bereitstellung, den Offline-Prüfungen und dem End-to-End-Ablauf und erfasse und triagiere anschließend die Ergebnisse. Als abgeschlossen gilt die Aufgabe, wenn blockierende Ergebnisse als behoben verifiziert sind, akzeptierte Einschränkungen öffentlich widergespiegelt werden und ein präziser, redigierter Pilotbericht auf die daraus entstehenden Issues verweist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
rust
Bereich
devops, documentation, infrastructure, release
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.