Viele Diskussionen betrachten den Start von Dusk als ein vollständiges Endergebnis, aber diesem Satz fehlt das wichtigste Subjekt. In einem offiziellen Websiten-Snapshot des Anbieters wird „Dusk Native L1“ als „Live“ markiert, „DuskEVM“ als „Testnet“, „Hedger“ als „Testnet“ und „Dusk Trade“ als „Building“. Diese vier Bezeichnungen stehen für unterschiedliche Ebenen: das Netzwerk selbst, den EVM-kompatiblen Ausführungspfad, datenschutzbezogene Module sowie die Richtung der Anwendungsschicht für tokenisierte Finanzwerte. Wenn man sie zu einem einzigen Status verdichtet, bringt man bereits bestehendes Netzwerk, testbare Funktionen und noch im Aufbau befindliche Produkte durcheinander.
Wenn das Problem im Team lautet, was man jetzt verifizieren kann, sollte man zuerst den Modulnamen nennen und dann dessen öffentlichen Status. Der „Live“-Snapshot von Native L1 kann nicht dazu dienen, DuskEVM als produktiv verfügbar anzukündigen; „Testnet“ für DuskEVM oder Hedger lässt sich auch nicht zu einer vollständigen Bereitstellung umdeuten; „Building“ für Dusk Trade bedeutet erst recht nicht, dass der Handel bereits eröffnet ist. Das ist kein Herunterkühlen, sondern schafft klare Grenzen für die Bewertung: Bei Diskussionen über die Settlement-Basis, Testpfade oder Pläne für die Anwendungsschicht ist die Aussagekraft der Evidenz unterschiedlich, und dementsprechend sollten auch die Urteile unterschiedlich ausfallen.
Für den Product Owner sind die nützlichsten Fragen nicht, ob Dusk „wirklich“ live ist, sondern wie diese von uns zu nutzende Ebene heißt, in welchem Zustand sie sich befindet und welche Schlüsse dieser Zustand erlaubt. Erst das Subjekt klären, dann Zweck und nächste Schritte besprechen—so werden pauschale Aussagen zu überprüfbaren technischen Urteilen.
Das erklärt auch, warum unter demselben Projektnamen gleichzeitig „Live“, „Testnet“ und „Building“ auftauchen. Diese Tags sind keine Wertung von gut nach schlecht, sondern Hinweise darauf, dass Leser unterschiedliche Verifikationsmethoden anwenden sollen: Für die bereits live geschaltete Basisschicht kann man über bestehende Netzwerkfakten sprechen; Testmodule sollte man auf den Versuchsbereich beschränken; die sich im Aufbau befindliche Anwendungsschicht sollte nur als öffentliche Richtung diskutiert werden.
@Dusk $DUSK #dusk
Wenn das Problem im Team lautet, was man jetzt verifizieren kann, sollte man zuerst den Modulnamen nennen und dann dessen öffentlichen Status. Der „Live“-Snapshot von Native L1 kann nicht dazu dienen, DuskEVM als produktiv verfügbar anzukündigen; „Testnet“ für DuskEVM oder Hedger lässt sich auch nicht zu einer vollständigen Bereitstellung umdeuten; „Building“ für Dusk Trade bedeutet erst recht nicht, dass der Handel bereits eröffnet ist. Das ist kein Herunterkühlen, sondern schafft klare Grenzen für die Bewertung: Bei Diskussionen über die Settlement-Basis, Testpfade oder Pläne für die Anwendungsschicht ist die Aussagekraft der Evidenz unterschiedlich, und dementsprechend sollten auch die Urteile unterschiedlich ausfallen.
Für den Product Owner sind die nützlichsten Fragen nicht, ob Dusk „wirklich“ live ist, sondern wie diese von uns zu nutzende Ebene heißt, in welchem Zustand sie sich befindet und welche Schlüsse dieser Zustand erlaubt. Erst das Subjekt klären, dann Zweck und nächste Schritte besprechen—so werden pauschale Aussagen zu überprüfbaren technischen Urteilen.
Das erklärt auch, warum unter demselben Projektnamen gleichzeitig „Live“, „Testnet“ und „Building“ auftauchen. Diese Tags sind keine Wertung von gut nach schlecht, sondern Hinweise darauf, dass Leser unterschiedliche Verifikationsmethoden anwenden sollen: Für die bereits live geschaltete Basisschicht kann man über bestehende Netzwerkfakten sprechen; Testmodule sollte man auf den Versuchsbereich beschränken; die sich im Aufbau befindliche Anwendungsschicht sollte nur als öffentliche Richtung diskutiert werden.
@Dusk $DUSK #dusk