#sign地缘政治基建 $SIGN Ich werde zunehmend auf eine Sache aufmerksam: Jedes Mal, wenn der Veranstaltungstext geändert wird, könnte das System darunter möglicherweise eine zusätzliche Schicht von unerklärten Anweisungen hinzufügen, die niemand ernsthaft berechnet hat. Viele berechtigte Veranstaltungen, Weißlisten und Anreizverteilungen ändern zuerst immer den Text. Eine weitere Einschränkung, ein weniger erklärender Satz, das Wort „Vorschlag“ in „muss“ ändern, „entspricht den Anforderungen“ in „bevorzugt berücksichtigen“ ändern – es scheint nur eine kleine Anpassung der betrieblichen Formulierungen zu sein, aber das eigentliche Problem ist, dass eine Änderung des Textes nicht bedeutet, dass die zugrunde liegende Ausführung ebenfalls geändert wurde.
Am Ende sieht man dann eine besonders vertraute Situation: Die Benutzer sehen eine neue Formulierung, während die Liste möglicherweise noch nach der alten Logik erstellt wird und die nachfolgende Erklärung in eine dritte Version wechselt. Der Prozess mag auf der Oberfläche noch funktionieren, aber tatsächlich erzeugt jede kleine Anpassung neue Mehrdeutigkeiten. Es liegt nicht daran, dass das Projekt keine Regeln hat, sondern dass die Regeln immer nur in der Anleitung festgehalten sind und das System selbst sie nicht wirklich erfasst hat.
Das ist auch der Grund, warum ich jetzt beim Betrachten von SIGN mehr darüber nachdenke. Die Bedeutung von Schema und Bestätigung besteht nicht nur darin, die Regeln aufzuschreiben, sondern auch darin, die Regeln und deren Ausführung so weit wie möglich miteinander zu verknüpfen. Was an der TokenTable wirklich interessant ist, sind nicht die „versendeten Dinge“, sondern ob diese Formulierungen zur Verteilung, Berechtigung und Freischaltung objektiviert und prozessiert werden können, anstatt sich immer auf den Text zu verlassen, um Lücken zu füllen. Für mich werden viele Projekte immer schwerer, nicht weil es nicht genug Regeln gibt, sondern weil die Regeln immer nur in der Anleitung herumschweben. Ob SIGN weiterhin von Interesse ist, interessiert mich weniger, als ob es gelingen kann, die Regeln weniger oft auf der Erklärungsebene festzuhalten.
@SignOfficial
Am Ende sieht man dann eine besonders vertraute Situation: Die Benutzer sehen eine neue Formulierung, während die Liste möglicherweise noch nach der alten Logik erstellt wird und die nachfolgende Erklärung in eine dritte Version wechselt. Der Prozess mag auf der Oberfläche noch funktionieren, aber tatsächlich erzeugt jede kleine Anpassung neue Mehrdeutigkeiten. Es liegt nicht daran, dass das Projekt keine Regeln hat, sondern dass die Regeln immer nur in der Anleitung festgehalten sind und das System selbst sie nicht wirklich erfasst hat.
Das ist auch der Grund, warum ich jetzt beim Betrachten von SIGN mehr darüber nachdenke. Die Bedeutung von Schema und Bestätigung besteht nicht nur darin, die Regeln aufzuschreiben, sondern auch darin, die Regeln und deren Ausführung so weit wie möglich miteinander zu verknüpfen. Was an der TokenTable wirklich interessant ist, sind nicht die „versendeten Dinge“, sondern ob diese Formulierungen zur Verteilung, Berechtigung und Freischaltung objektiviert und prozessiert werden können, anstatt sich immer auf den Text zu verlassen, um Lücken zu füllen. Für mich werden viele Projekte immer schwerer, nicht weil es nicht genug Regeln gibt, sondern weil die Regeln immer nur in der Anleitung herumschweben. Ob SIGN weiterhin von Interesse ist, interessiert mich weniger, als ob es gelingen kann, die Regeln weniger oft auf der Erklärungsebene festzuhalten.
@SignOfficial