El ascensor del complejo falla constantemente. En el grupo de propietarios, alguien publicó un plan de mejoras. Al principio pensé que, como había muchos votos, ya podrían empezar las obras; luego descubrí que también hay que presentar ofertas, realizar evaluaciones, hacer pruebas de construcción y finalmente la aceptación. También es fácil que el gobierno en cadena se malinterprete por rapidez: se publica una propuesta, solo se explica que las discusiones ya tienen un soporte formal, pero el código de la red principal no cambia de inmediato.
Dusk organiza las modificaciones del acuerdo en un DIP, es decir, Dusk Improvement Proposal. El proceso oficial empieza con la Idea; cuando la idea toma forma, entra en Draft y obtiene un número. Después, si se hace un prototipo o un logro técnico, pasa a Feedback. Cuando está cerca de completarse, se mueve a Staging. Los DIP que implican código primero se colocan en la red de pruebas Nocturne; solo después de recibir consenso se marcan como Active e integran el resultado en el entorno de producción.#dusk
Me gusta algo de este proceso: los cambios al protocolo DUSK deben dejar un expediente completo. La propuesta tiene que describir la motivación, especificaciones técnicas, compromisos y renuncias, compatibilidad hacia atrás, pruebas, impactos en seguridad y enlaces de implementación. Las propuestas Stagnant que no sigan desarrollándose durante medio año incluso podrían pasar a Dead. Al mirar atrás una actualización, la comunidad puede rastrear qué riesgos se discutieron en ese momento, en lugar de solo ver comunicados de nuevas versiones.
Pero que “cualquiera pueda presentar” no implica directamente que “cualquiera pueda cambiar las reglas”. Los editores de DIP participan en la revisión, asignación de números, fusión y seguimiento de la implementación; además, los operadores de nodo deben instalar el software que incluye las modificaciones. Las aclaraciones públicas actuales no proporcionan un umbral de votación calculado con base en las tenencias según $DUSK , ni establecen el “logro de consenso” como un porcentaje explícito. No voy a empaquetar una discusión abierta como si ya hubiera concluido un gobierno en cadena.
Al prestar atención a la actualización de @Dusk , verificaré por separado cuatro cosas: en qué estado se encuentra el DIP, si el código de la implementación es público, si los resultados de las pruebas en Nocturne pueden verificarse de nuevo y cuándo adoptarán los nodos en la red principal. Los likes en el grupo solo indican que la idea es bien recibida; solo Active y el despliegue real demuestran en qué etapa del recorrido de las reglas de Dusk se encuentra.
Dusk organiza las modificaciones del acuerdo en un DIP, es decir, Dusk Improvement Proposal. El proceso oficial empieza con la Idea; cuando la idea toma forma, entra en Draft y obtiene un número. Después, si se hace un prototipo o un logro técnico, pasa a Feedback. Cuando está cerca de completarse, se mueve a Staging. Los DIP que implican código primero se colocan en la red de pruebas Nocturne; solo después de recibir consenso se marcan como Active e integran el resultado en el entorno de producción.#dusk
Me gusta algo de este proceso: los cambios al protocolo DUSK deben dejar un expediente completo. La propuesta tiene que describir la motivación, especificaciones técnicas, compromisos y renuncias, compatibilidad hacia atrás, pruebas, impactos en seguridad y enlaces de implementación. Las propuestas Stagnant que no sigan desarrollándose durante medio año incluso podrían pasar a Dead. Al mirar atrás una actualización, la comunidad puede rastrear qué riesgos se discutieron en ese momento, en lugar de solo ver comunicados de nuevas versiones.
Pero que “cualquiera pueda presentar” no implica directamente que “cualquiera pueda cambiar las reglas”. Los editores de DIP participan en la revisión, asignación de números, fusión y seguimiento de la implementación; además, los operadores de nodo deben instalar el software que incluye las modificaciones. Las aclaraciones públicas actuales no proporcionan un umbral de votación calculado con base en las tenencias según $DUSK , ni establecen el “logro de consenso” como un porcentaje explícito. No voy a empaquetar una discusión abierta como si ya hubiera concluido un gobierno en cadena.
Al prestar atención a la actualización de @Dusk , verificaré por separado cuatro cosas: en qué estado se encuentra el DIP, si el código de la implementación es público, si los resultados de las pruebas en Nocturne pueden verificarse de nuevo y cuándo adoptarán los nodos en la red principal. Los likes en el grupo solo indican que la idea es bien recibida; solo Active y el despliegue real demuestran en qué etapa del recorrido de las reglas de Dusk se encuentra.
