MIP0 - en español

El Marco de Trabajo de las Propuestas de Mejoras Maker (MIP) - en Español

Sumario abreviado

La MIP0 define y describe el marco de trabajo de las MIPs.

Sumario extendido

La MIP0 es la propuesta primigenia que describe el marco de trabajo de las MIPs. Esto incluye los componentes centrales y los estados así como los diversos tipos de MIP y el ciclo de vida general de las mismas. La MIP0 provee también las herramientas necesarias, tales como los modelos de MIP, los procesos de reemplazo y las dependencias. Por último, la propuesta detalla los roles clave del marco de trabajo, el Editor de MIP y el Facilitador de Gobernanza, así como el proceso para añadirlos y removerlos.

Sumario de componentes

MIP0c1: Definición del marco de trabajo de la Propuesta de Mejoras Maker

Define varios conceptos importantes para entender el proceso de las MIPs.

MIP0c2: Principios centrales

Elabora algunos principios centrales que toda MIP debería tener como norte.

MIP0c3: El ciclo de vida de las MIPs

Describe cómo se crea una MIP y su derrotero hasta su Aceptación o Rechazo.

MIO0c4: Componentes de las MIPs y tipos de componentes de las MIPs

Elabora el uso de componentes para compartimentalizar y organizar las MIP.

MIO0c5: Proceso de reemplazo de las MIPs

Elabora cómo pueden reemplazarse las MIPs y cuáles son los pasos a seguir para mantener las dependencias.

MIO0c6: Materiales de apoyo

Un componente que define cómo incluir materiales externos en las MIPs.

MIP0c7: Modelos de las MIPs

Define los modelos para las MIPs generales y técnicas.

MIP0c8: Dependencias de roles de dominio de MIP0

Define los roles centrales necesarios para la operación exitosa de las MIPs.

MIP0c9: Lista de roles del personal central

Lista del personal que actualmente ocupa roles centrales.

MIP0c10: Rol del Editor de MIP

Un componente que define las responsabilidades, los criterios y los causales de remoción del rol de Editor de MIP.

MIP0c11: Rol de Facilitador de Gobernanza

Un componente que define las responsabilidades, los criterios y los causales de remoción del rol de Facilitador de Gobernanza.

MIP0c12: Incorporación de personal central

Un componente de proceso que define el proceso de adición de personal a los roles de Editor de MIP o Facilitador de Gobernanza.

MIP0c13: Remoción de personal central

Un componente de proceso que define el proceso de remoción de personal de los roles de Editor de MIP o Facilitador de Gobernanza.

Motivación

MakerDAO está evolucionando en una organización sin intermediarios, totalmente descentralizada, de código abierto y autosustentable. Con el fin de mantener y promover esta evolución gradual sin dejar de sostener la funcionalidad de la gobernanza tanto durante la disolución de la Fundación Maker como después de ella, Maker será legislado por medio de Propuestas de Mejoras Maker (MIPs).

El propósito del marco de trabajo de MIP es posibilitar que cualquier miembro de la comunidad pueda hacer su aporte para la mejora de la Gobernanza y del Protocolo Maker.

El empoderamiento de la comunidad y de otras partes interesadas mediante la estandarización de la propuesta de mejoras, especificaciones o cambios de procesos o de estados, persigue el objetivo de hacer posible el crecimiento orgánico que llevará a MakerDAO más y más cerca de la autosustentabilidad.

Para que las MIPs sean funcionales es necesario que cumplan con un estándar básico que describa su estructura interna y sus dependencias externas. Este estándar es el descripto en MIP0, el marco de trabajo de las Propuestas de Mejoras Maker.

Especificación / Detalles de las propuestas

**MIP0c1: Definiciones del marco de trabajo de la Propuesta de Mejoras Maker ****

  • **Propuestas de Mejoras Maker (MIPs): son el mecanismo preferente para la mejora de la Gobernanza y del Protocolo Maker. Por medio de un proceso abierto y documentado, el objetivo es hacer acopio de tanto feedback comunitario como sea posible y alcanzar el consenso más amplio posible en relación a cómo debería evolucionar el Protocolo Maker. Una propuesta define claramente cómo y por qué la Gobernanza o el Protocolo Maker deberían ser modificados y garantiza que esta mejora sea incorporada de una manera responsable y respetando los estándares de calidad, de seguridad y comunitarios más altos.
  • MIP0: El MIP primigenio que define el marco de trabajo MIP. Este MIP define todos los procesos necesarios para la implementación de futuras MIPs.
  • Conjunto de MIP: Un conjunto de MIPs es un grupo de varios MIPs interdependientes de tal manera que, sin la totalidad de los MIPs considerados, uno o más MIPs del conjunto se vuelven inconsistentes, inválidos o absurdos. La intención es que los conjuntos de MIPs describan un único comportamiento complejo de modo tal que cada MIP pueda ser escrito siguiendo el principio de Especificidad sin que el conjunto deje de funcionar como un todo cohesivo y coherente.
  • Tipos de MIP: Las MIPs están separadas según tipo y cada tipo tiene su propia lista de MIP y de procesos.
  • MIP de Proceso: Las MIPs de Proceso se usan para crear y definir un proceso recurrente específico que será empleado por el Protocolo Maker o por la Gobernanza.
  • Subpropuestas (SP): Una subpropuesta es una instancia de un subproceso que ha sido definido por una MIP específica. Las subpropuestas son nombradas según el siguiente formato: MIP0-SP1 (donde MIP0 es una MIP de Proceso y MIP0-SP1 es una subpropuesta bajo esa MIP de Proceso)
  • Período Mínimo de Feedback: La cantidad mínima de tiempo dentro del cual la comunidad puede dar feedback en respuesta a una MIP.
  • Período mínimo de Congelamiento: La cantidad mínima de tiempo que una MIP debe permanecer sin cambios (congelada) antes de poder ser presentada para su ratificación/implementación.
  • Facilitador(es) de Gobernanza: Los Facilitadores de Gobernanza tienen la tarea de garantizar la operación correcta del proceso de Gobernanza. Esto involucra un abanico de actividades amplio: desde la administración general hasta el acopio de opinión y la planificación de la Gobernanza.
  • Editor(es) de MIP: Los Editores de MIP controlan los aspectos administrativos y editoriales del programa de MIP y de sus procesos. Se espera que el programa comience con un(a) editor(a) provisional de la Fundación Maker y que otras personas se unan más tarde.
  • Equipos de Dominio: Los Equipos de Dominio trabajan para el DAO, son incorporados a través de la Gobernanza y costeados por el Protocolo. Los Equipos de Dominio llevan a cabo tareas definidas por el DAO, tales como la supervisión de procesos críticos y la mitigación de riesgos. Estos equipos consisten en Riesgos, Oráculos, Contratos Inteligentes o Legal, aunque sin limitarse a ellos.

MIP0c2: Principios Centrales

  1. Especificidad: Una MIP debe definir y tratar un comportamiento específico o una responsabilidad particular. No se permitirán MIPs con muchos comportamientos o responsabilidades diferentes; las propuestas con esa característica deberán ser seccionadas en múltiples MIPs.
    • Esto minimiza los peligros de la “letra chica” o de ataques potenciales ocultos en MIPs grandes y complejas.
  2. Completitud: Una MIP o un Conjunto de MIPs están completos si tienen todas las partes necesarias o apropiadas para definir un comportamiento completo en lugar de ser sólo una parte específica de un todo mayor.
    • Esto es importante para la inteligibilidad, la legibilidad y la accesibilidad de las MIPs.
  3. Evitar la superposición: El mismo comportamiento no debería ser implementado independientemente por múltiples MIPs. Por ejemplo, no debería haber dos maneras distintas e intercambiables de hacer incorporación de colaterales.
    • De este modo el proceso primario y mejor comprendido para cada comportamiento particular estará imparcialmente disponible para todo el mundo; esto evitará el surgimiento de lagunas en el conocimiento que permitan a algunos actores mejor informados usar procesos potencialmente superiores.
  4. Claridad: Una MIP no debe ser susceptible de interpretaciones igualmente válidas y contradictorias. Los autores de MIP y los Editores de MIP deben esforzarse por minimizar la ambigüedad. Una MIP debe ser tan clara y sencilla de entender como sea posible.
    • Una MIP ambigua es una potencial causa de discordia o confusión a futuro. Hacer todo tan claro como sea posible también mejora la legibilidad y ayuda a mitigar el riesgo de ataques ocultos.
  5. Brevedad: Una MIP debe ser tan corta como sea posible e incluir solo lo esencial, dados los otros principios centrales.
    • Las MIPs más breves tienen más chances de ser leídas de principio a fin por los participantes del gobierno. A su vez esto sirve para reducir el terreno susceptible de ataques ocultos.

MIP0c3: El Ciclo de Vida de las MIP

El Ciclo de Vida de las MIPs y los Estados de las MIPs

Criterios para los Estados de las MIP

1. Concepción: El ciclo de vida de una MIP comienza con su posteo en el foro de Maker. Sin embargo, para que la MIP pase a la siguiente etapa es necesario que satisfaga los criterios de transición (1) aquí definidos:

  • Debe ser publicada en el foro MIPs Discourse.
  • Debe ser subida al repositorio de MIP de Github (con un Pull Request creado por el autor de la MIP o por el Editor de MIP).
  • El formato debe seguir el modelo MIP apropiado para su tipo.
  • Las MIPs deben ser originales o reemplazos de MIPs anteriores. (Las repeticiones no están permitidas).

2. Aprobación por parte de los Editores de MIP: En esta fase de su ciclo de vida los Editores de MIP verifican que la MIP siga la estructura y los criterios editoriales correctos según los define el modelo de MIP. Si la MIP no satisface los criterios arriba expuestos, los Editores de MIP comunicarán las razones del rechazo al autor de la MIP y le darán la oportunidad de hacer las modificaciones pertinentes antes de reconsiderar la propuesta. Si en cambio la MIP satisface los criterios antedichos, los Editores de MIP llevarán a cabo estas acciones:

  • La MIP será aprobada por un Editor de MIP y se le asignará un número de MIP formal.
  • El PR será incorporado por un Editor de MIP.

3. Request for Comments (RFC) (Petición de comentarios): En esta fase la MIP atraviesa un periodo de revisión formal que incluye: feedback comunitario, refinamiento del documento y adiciones. El eje cronológico para la fase RFC se define por su Periodo de Feedback y por su Periodo de Congelamiento. Antes de avanzar a la próxima fase, la MIP debe satisfacer los criterios de transición aquí definidos:

  • Basándose en el feedback comunitario, el autor de la MIP modifica la MIP y ultima detalles.
  • Las MIP tienen un Periodo de Feedback de 3 meses. La fase RFC tiene una duración mínima de 3 meses; la MIP no puede avanzar de fase antes de que sea cumplida esta duración mínima.
  • Las MIP tienen un Periodo de Congelamiento de 1 mes. Antes de avanzar a la próxima fase, las MIP tienen que permanecer sin cambios durante el último mes inmediatamente previo al momento de su promoción.

4. Requerimientos del Periodo de Feedback Cumplidos: Este estado le es otorgado a la MIP una vez atravesados el Periodo de Feedback y el Periodo de Congelamiento. Solo entonces la MIP está lista para su Presentación Formal. Nótese que el Periodo de Feeback y el Periodo de Congelamiento pueden superponerse.

5. Presentación Formal: En esta fase, los autores de una MIP presentan su MIP completa al ciclo de Gobernanza, postéandolo en la categoría de presentación formal del foro dentro del lapso de presentación formal de un ciclo de Gobernanza.

  • Una MIP puede ser presentada nuevamente al proceso de presentación formal hasta un máximo de dos veces más (tres en total), sin tener que pasar por las fases 1-4 otra vez, si no logró pasar debido a razones externas legítimas (ej. no fue considerada aisladamente sino como parte de una encuesta de Gobernanza o en un voto ejecutivo con una propuesta pólemica - sujeto al juicio de los Facilitadores de Gobernanza)

6. Aprobado por los Facilitadores de Gobernanza: En esta fase, la MIP debe ser formalmente aprobada por un Facilitador de Gobernanza.

  • Una vez aprobada por el Facilitador de Gobernanza, la MIP estará incluida en la encuesta de inclusión del ciclo de Gobernanza.
  • Si la MIP no es aprobada por el Facilitador de Gobernanza, podrá ser reconsiderada en una fecha ulterior para entrar en el ciclo de Gobernanza.

7. Ciclo de Gobernanza: En esta fase, los accionistas MKR votan para decidir si la MIP será incluida en la encuesta de Gobernanza o no, determinando si la MIP puede entrar en el ciclo de Gobernanza formalmente o no.

  • Una vez aprobada para la encuesta de Gobernanza, los accionistas MKR determinan si se aceptará o se rechazará el conjunto de propuestas en la encuesta de Gobernanza y ratifican finalmente el resultado en el voto ejecutivo.

8. Voto Ejecutivo: En esta fase, la MIP se vuelve oficialmente ratificada o no. Siendo determinado por los accionistas MKR, el voto ejecutivo acepta o rechaza la MIP definitivamente.

9. Aceptado/Rechazado: El voto ejecutivo resulta en la aceptación o en el rechazo de la MIP. Si pasa, la MIP es oficialmente aceptada y se le da el estado de aceptada. Si el voto ejecutivo no logra pasar antes de su expiración, la MIP es rechazada.

  • Como se describió en la fase 5, una MIP rechazada puede ser presentada nuevamente y, en algunos casos (por ejemplo, si puede constatarse que fue rechazada en base a argumentos irrelevantes), puede ser autorizada para entrar al ciclo de Gobernanza siguiente inmediatamente.

Otros Estados de MIP:

Retirado: Cuando un autor de una MIP retira su propuesta, como cuando:

  • Una MIP puede ser retirada en cualquier momento antes de entrar al ciclo de Gobernanza.
  • Nótese que una propuesta retirada puede ser tomada de su autor original con una simple transición facilitada por el/los Editor/es de MIP y las partes respectivas. Si el autor original de la MIP no está más disponible, el Editor de MIP puede proceder con la transferencia de autoría.

Diferido: Cuando una propuesta ha sido considerada como no lista o no prioritaria pero puede ser presentada nuevamente en una fecha ulterior.

  • Request for Comments (RFC) - Petición de Comentarios: La encuesta del foro o la solicitud de señal rechaza una propuesta de MIP.

Obsoleto: Cuando una propuesta no se usa más o está desactualizada, por ejemplo:

  • Una MIP es remplazada con una nueva propuesta.
  • Una MIP ha sido diferida por más de seis meses.
  • Un autor de una MIP abandonó la propuesta y ninguna otra persona ha comunicado la voluntad de responsabilizarse de la autoría de la MIP.
  • Una MIP ha sido remplazada por una propuesta de MIP más reciente y más actualizada.
  • No tiene sentido seguir considerando una cierta MIP.

Proceso de Cambio de Estado de una MIP:

Un cambio de estado para una MIP es solicitado por el autor de una MIP y será revisado por el/los Editores de MIPs para evaluar si cumple con los criterios del cambio de estado requerido. Si así es, el/los Editor/es cambiarán el estado de la MIP y el autor puede proceder con la siguiente etapa del proceso. Si no es así, el/los editor/es de MIP deberán hacer un retorno destacando los problemas y el autor deberá arreglar esos problemas antes de solicitar otro cambio de estado.

MIP0c4: Los Componentes de MIP y los Tipos de Componentes de MIP

Componentes de MIP

  • Cuando necesario, las MIPs pueden tener múltiples componentes si necesita contener múltiples unidades de lógica para satisfacer la completitud. Una MIP puede tener un componente único.
  • Los componentes de MIP están categorizados por tipos, dependiendo del tipo de lógica que contienen. Los componentes MIP están nombrados en relación a su MIP madre. La convención de abreviación MIPXcY es utilizada para hacer referencia a estos componentes (como se explica en este documento).
  • Un componente MIP tiene un tipo o ningún tipo.

Tipos de componentes

  • Componente MIP de proceso

    Sumario: El propósito de un componente MIP de proceso es definir un flujo de proceso específico que la Comunidad Maker adopte y estandarice con respecto a la operación de Gobernanza. Este tipo de componente MIP ayuda a homologar procesos específicos de manera transparente, abierta y trazable. Una MIP de Proceso proveerá un ámbito públicamente documentado del marco del proceso propuesto así como una descripción detallada de la estructura de la subpropuesta.

    Modelo especial: N/A

    Notas importantes:

    • Un componente MIP de proceso debe definir el Periodo de Feedback y el Periodo de Congelamiento para sus subpropuestas.
    • Las subpropuestas de componentes MIP de proceso con tipos de componentes MIP adicionales heredan los mismos tipos.
  • Subpropuestas

    Sumario: Una supropuesta de un proceso expeditado que se define dentro de una MIP y que da las pautas de ejecución de un proceso dado dentro del marco de trabajo de las MIP.

  • Las subpropuestas requieren un modelo, un Periodo de Feedback y un Periodo de Congelamiento y deben ser presentadas usando ese modelo. Las subpropuestas atraviesan el proceso MIP del mismo modo que las MIP completas. El modelo, el Periodo de Feedback y el Periodo de Congelamiento para un conjunto de subpropuestas se definen mediante un componente MIP llamado Componente de Proceso. A toda MIP que contenga un Componente de Proceso se le asigna el tipo Proceso.

  • La convención para el nombramiento de subpropuestas es MIPXcY-SPZ, donde Y es el Componente de Proceso que contiene el modelo de la subpropuesta y X es la MIP que contiene ese componente. Esto es importante para poder delimitar diferentes tipos de subpropuestas definidas en la misma MIP bajo distintos Componentes de Proceso.

Modelo especial: N/A


MIP0c5: Proceso de Reemplazo de MIP

Una MIP puede definir en su preámbulo uno o más objetivos a reemplazar. Si la MIP obtiene el estado Aceptada, la MIP a reemplazar recibe el estado Obsoleta y es efectivamente desactivada. La MIP reemplazada indicará en su documento MIP el número de la MIP que la reemplazó. Las MIPs que dependían de la MIP ahora obsoleta interactuarán con la nueva MIP.

Debido a que las dependencias se trasladan, una MIP que define objetivos a reemplazar debe —para ser válida— adherirse estrictamente a los requisitos de dependencia e interactuar correctamente con las MIP que dependen de la MIP reemplazada.


MIP0c6: Materiales de apoyo

Opcionalmente, las MIP pueden hacer referencia a materiales externos. Los materiales externos deben ser añadidos al github de MIP en la misma carpeta que la MIP que los referencia.

Los materiales referidos externamente no son contenido MIP y no son ratificados cuando una MIP es aceptada — a menos que expresamente se indique lo contrario en una especificación de componente de MIP.


MIP0c7: Modelos de MIP

Modelo de MIP General

  • El Modelo de MIP General debería ser usado cada vez que un modelo rafiticado más específico resulte no ser del todo apropiado.
  • El Modelo de MIP General se encuentra en General-MIP-Template.md. Este modelo se considerará ratificado una vez que el estado de esta MIP es Aceptado.

Modelo de MIP Técnica

  • El Modelo de MIP Técnica debería ser usado cada vez que una MIP proponga cambios del código de contratos inteligentes dentro del Protocolo Maker.
  • El Modelo de MIP Técnica se encuentra en Technical-MIP-Template.md. Este modelo se considerará ratificado una vez que el estado de esta MIP sea Aceptado.

MIP0c8: MIP0 Dependencias de Roles de Dominio

El marco de trabajo de MIP depende de estos tipos de Roles de Dominio:

  • Editor(es) de MIP: Los Editores de MIP controlan los aspectos administrativos y editoriales del programa de MIP y de sus procesos. Se espera que el programa comience con un editor provisional de la Maker Foundation y que otras personas se unan más tarde.
  • Autoridad específica del Editor de MIP en los procesos MIP0:
    • El Editor de MIP controla la fase 2 del ciclo de vida de las MIPs y tiene la potestad de asignar números MIP
    • El Editor de MIP es admin en el repositorio de MIP de Github
    • El Editor de MIP es moderador en el foro MIPs Discourse
    • El Editor de MIP es responsable de la actualización del estado de las MIPs, según se describe en MIP0c4 “El Ciclo de Vida de las MIPs”.
  • Facilitador de Gobernanza: Gestiona frontends de votación, lleva a efecto reuniones de Gobernanza y acepta MIPs que están listas para ser incluidas en el Ciclo de Gobernanza y, en consecuencia, para que se las vote.
  • Autoridad específica del Facilitador de Gobernanza en los procesos MIP0:
    • El consenso de todos los Facilitadores de Gobernanza controla la fase 6 del ciclo de vida de las MIP; esto les permite, de forma consensuada, añadir MIPs válidas a la encuesta de inclusión del próximo Ciclo de Gobernanza, avanzándolas desde la fase 5 (presentación formal) a la fase 7 (Ciclo de Gobernanza).

La adición de personal a estos roles puede hacerse usando una subpropuesta MIP0c10.La remoción de personal de estos roles puede hacerse usando una subpropuesta MIP0c11.


MIP0c9: Lista de Roles del Personal Central

Esta lista puede enmendarse a través de los componentes de MIP0 de incorporación (MIP0c12) y de remoción (MIP0c13) de personal central.

Las entradas en esta lista deberían seguir este modelo:

- Nombre de la persona: El nombre de la persona en el rol central.
	- Número de subpropuesta (MIP0c12-SP): #
	- Rol central: El rol central en que esta persona opera
	- Fecha de adición: <fecha en formato (aaaa-mm-dd)>

Lista de Personal Central Activo:

  1. Facilitadores de Gobernanza:
  1. Editores de MIP:
  • Nombre de la persona: Charles St.Louis
    • Número de Subpropuesta (MIP0c12-SP): 1
    • Rol Central: MIP Editor
    • Fecha de Adición: 2020-05-02 (Ratification Vote)

MIP0c10: Rol de Editor de MIP

Responsabilidades

El Editor de MIP controla los aspectos administrativos y editoriales generales del proceso MIP y de su marco de trabajo. Esto incluye:

  • Mantenimiento y gestión de mips.makerdao.com.
  • Provisión de feedback y sostenimiento de discusiones en la sección de MIP de forum.makerdao.com (por ejemplo: colaborar con el veto de ideas de propuestas).
  • Procesamiento de MIP.
  • Gestión y organización de MIP y de Preámbulos de Subpropuestas.
  • Incorporación y veto de nuevos Editores de MIP.
  • Afianzamiento de los procesos de MIP apropiados con responsabilidades tales como:
    • Verificar que el título describa adecuadamente el contenido de la propuesta.
    • Verificar la existencia real de autores, coordinadores, financiadores y/o patrocinadores, etcétera, de las MIPs.
    • Asignar a las MIPs propuestas sus números de identificación formales.
    • Cambiar los estados de las MIPs.
    • Corregir el posicionamiento categórico de las MIPs.
    • Mantener comunicación con coordinadores o autores de MIPs.
    • Revisar las MIPs e identificar problemas en su redacción (formato, completitud, ortografía, gramática, estructura oracional) y comprobar que no se aparten de la guía de estilo (del modelo). Los Editores de MIP tienen la potestad de hacer correcciones ellos mismos; no obstante, no están obligados a hacerlo y en cambio pueden enviarles comentarios a los autores para que ellos mismos hagan las enmiendas pertinentes.
    • Trabajar con los Facilitadores de Gobernanza y mantener comunicación con ellos con respecto a la coordinación de Votos Ejecutivos y de Gobernanza en relación a las MIPs y el Ciclo de Gobernanza.

Criterios de selección

Al seleccionar un Editor de MIP deberían considerarse estos criterios:

  • Una comprensión cabal del marco de trabajo de MIP
  • Aunque habrá un transvase de conocimiento al momento de la incorporación, el candidato debe estar muy familiarizado con el marco de trabajo y con la operación general de otros marcos de trabajo de propuestas de mejoras.
  • Es necesario haber sido miembro de la Comunidad durante algún tiempo. Esto puede demostrarse por medio de diversas pruebas de participación, como por ejemplo:
    • El historial de posteos en el foro
    • Asistencia en las llamadas comunitarias y de Gobernanza
    • Autoría de artículos sobre Maker o Dao
  • Familiaridad con los aspectos técnicos internos del Protocolo Maker (extra)
  • Experiencia con Github
    • Haciendo merges, editar, y cerrar los Pull Requests
    • Hacerse cargo de problemas
    • Añadir tags/labels
  • Experiencia con el lenguaje Markdown
    • Las MIPs serán escritas en Markdown, de modo que los editores deberán estar familiarizados con el lenguaje

Adición

Una vez incorporada una persona al rol de Editor de MIP, se la añadirá también a Github y se la subscribirá para monitorear el repositorio de MIP. Asimismo se la designará como moderador en el canal de MIP de Rocket.Chat y en el foro de MIP. Muchos de los intercambios y comunicaciones en relación con MIP se canalizarán mediante GitHub y/o los foros de MakerDAO.

Remoción

Se considerará la remoción de un Editor de MIP si resulta que este:

  • No está llevando a cabo las tareas que le corresponden de manera adecuada
  • Se ausenta de sus tareas por un periodo prolongado
  • Da muestras de comportamiento poco ecuánime o malicioso
  • Expresa su renuencia a continuar desempeñándose en el rol

El proceso de remoción comienza una vez que la Comunidad ha examinado y encontrado válidas las causales de remoción. Este proceso debe ser comunicado públicamente vía los foros para asegurar una completa transparencia. El Editor de MIP será entonces removido de los siguientes canales:

  • Github
  • RocketChat
  • Forums

MIP0c11: Rol del Facilitador de Gobernanza

Responsabilidades

Las responsabilidades del Facilitador de Gobernanza se definen de este modo:

Responsabilidades Centrales

  • Es responsable de garantizar la salud y la integridad de los canales de comunicación usados para la comunicación interna de MakerDAO. Esto incluye actividades tales como tareas de moderación, el establecimiento de procesos y normas sociales y la defensa de los canales contra trolleo y ataques Sybil.
  • Es necesario que permanezca neutral y objetivo acerca de asuntos externos al dominio de la Gobernanza y que se enfoque en las medidas, los procedimientos y la facilitación.
  • Es necesario que programe, lleve a cabo y modere reuniones de Gobernanza y Riesgo semanales desde una posición neutral.
  • Es necesario que organice y lleve a cabo procesos de Gobernanza según lo indicado por las MIPs o conjuntos de MIP relevantes cuyo estado sea Aceptado.
  • Es necesario que cree encuestas on-chain en el frontend de votación “oficial” según lo indicado por procesos de gobernanza definidos de las MIPs o conjuntos de MIP relevantes cuyo estado sea Aceptado.
  • Debería promover una cultura de apertura, receptividad y discusiones razonadas dentro de la Comunidad.
  • Debería trabajar con la Comunidad para operar un proceso de votación de emergencia para proteger el sistema ante la irrupción de una emergencia.
  • Debería incorporar y luego mantener cómo mínimo tres Facilitadores de Gobernanza en todo momento; debería priorizar candidados de regiones geográficas subrepresentadas.

Animar la Participación

  • Debería trabajar en pos de mantener y animar el debate sano de acuerdo a las pautas delineadas en el Marco Científico de Gobernanza y Riesgo y los Principios Centrales de la Fundación
  • Debería garantizar que la agenda de eventos de la Gobernanza por suceder se comunique adecuadamente a todas las partes interesadas con un mínimo de antelación de una semana.
  • Debería apuntar a promover e incrementar la participación de las partes interesadas en el proceso de Gobernanza.
  • Debería garantizar que los nuevos miembros de la comunidad entiendan cuál es el nivel de decoro y civismo generalmente esperado dentro del grupo; también debería garantizar que tengan los recursos que necesitan para incorporarse rápidamente.

Aumentar la eficiencia

  • Debería garantizar que se apliquen “consensus gathering methods” una vez la discusión alcance su fin natural.
  • Debería apoyar y facilitar las comunicaciones entre otros actores autorizados en el Protocolo Maker.
  • Debería estar atento a oportunidades de homologar el proceso de Gobernanza sin sacrificar la integridad de este.

Cohesión y moral

  • Es responsable de elevar los problemas de Gobernanza que encuentre a la Fundación Maker o al ecosistema tercerizado y de garantizarle a la comunidad un seguimiento apropiado.
  • Debería ayudar a generar y a mantener la moral y la participación entre los miembros de la Comunidad de Gobernanza.
  • Debería animar a la comunidad a alcanzar consensos sobre las opciones menos objetables y no tomar el proceso de toma de decisiones como una competencia en que una parte de la Comunidad debe resentir el resultado.
  • Debería trabajar para acercar las posturas de los miembros de la Comunidad de Gobernanza cuando se traten temas controvertidos con el fin de evitar la polarización política y la demagogia.

Criterios de selección

Al evaluar a una persona para el rol de Facilitador de Gobernanza deberían usarse los siguientes criterios:

  • Debería tener una comprensión cabal del marco de trabajo de MIPs y de su contenido, sobre todo en relación a las MIPs de Gobernanza centrales
  • Es necesario haber sido miembro de la Comunidad durante algún tiempo. Esto puede demostrarse por medio de diversas pruebas de participación, como por ejemplo:
    • El historial de posteos en el foro
    • Asistencia en las llamadas comunitarias y de Gobernanza
    • La existencia de contribuciones en relación a problemas de Gobernanza con independencia del medio por que se hayan canalizado.
  • Aunque se impartirá conocimiento al momento de la incorporación, al candidato deben serle familiares los roles y las responsabilidades de los Facilitadores de Gobernanza.
  • Debería estar familiarizado con el funcionamiento técnico interno del Procolo Maker (extra).
  • Debe tener experiencia interactuando con diferentes partes interesadas de la Comunidad en todos los medios que esta usa para comunicarse, incluyendo salas de chat, foros y llamadas de videoconferencia.
  • Debería ser capaz de expresarse con confianza en cada uno de los medios que la Comunidad usa para comunicarse, incluyendo salas de chat, foros y llamadas de videoconferencia.
  • Debería interesarse por los mecanismos de Gobernanza usados actualmente en el mundo y por aquellos que han sido usados históricamente.

Remoción

Se considerará la remoción de un Editor de MIP si resulta que este:

  • No está llevando a cabo las tareas que le corresponden de manera adecuada
  • Se ausenta de sus tareas por un periodo prolongado
  • Da muestras de comportamiento poco ecuánime o malicioso
  • Expresa su renuencia a continuar desempeñándose en el rol

El proceso de remoción comienza una vez que la comunidad ha examinado y encontrado válidas las causales de remoción. Este proceso debe ser comunicado públicamente vía los foros para asegurar una completa transparencia. El Facilitador de Gobernanza será entonces removido de los siguientes canales:

  • Github
  • RocketChat
  • Forums

MIP0c12: Incorporación de Personal Central

MIP0c12 es un componente MIP de Proceso que permite la incorporación de personal central a través de una subpropuesta. Las subpropuestas de MIP0c12 tienen los siguientes parámetros:

  • Periodo de Feedback: 3 meses
  • Periodo de Congelamiento: 1 mes

Las subpropuestas de MIP0c12 deben usar el modelo ubicado en MIP0c12-Subproposal-Template.md. Este modelo se considerará ratificado una vez el estado de esta MIP pase a Aceptado.


MIP0c13: Remoción de Personal Central

MIP0c13 es un componente MIP de Proceso que permite la remoción de personal a través de una subpropuesta. Las subpropuestas MIP0c13 tienen los siguientes parámetros:

  • Periodo de Feedback: 0 días
  • Periodo de Congelamiento: 0 días

Las subpropuestas MIP0c13 deben usar el modelo ubicado en MIP0c13-Subproposal-Template.md. Este modelo se considerará ratificado una vez el estado de esta MIP pase a Aceptado.


Este documento es una traducción libre del artículo original. Gracias a @blimpa y @Gala por la traducción.

4 Likes