owned this note
owned this note
Published
Linked with GitHub
---
tags: MIPs Español
---
# MIP0 - Spanish
## Sumario abreviado
La MIP0 define y describe el framework de las MIP.
## Sumario extendido
La MIP0 es la propuesta primigenia que describe el framework de las MIP. 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 framework, el Editor de MIP y el Governance Facilitator, así como el proceso para añadirlos y removerlos.
## Sumario de componentes
**MIP0c1: Definición del Framework de Maker Improvement Proposal**
Define varios conceptos importantes para entender el proceso de las MIP.
**MIP0c2: Principios centrales**
Elabora algunos principios centrales que toda MIP debería tener como norte.
**MIP0c3: El ciclo de vida de las MIP**
Describe cómo se crea una MIP y su derrotero hasta su Aceptación o Rechazo.
**MIO0c4: Componentes de las MIP y tipos de componentes de las MIP**
Elabora el uso de componentes para compartimentalizar y organizar las MIP.
**MIO0c5: Proceso de reemplazo de las MIP**
Elabora cómo pueden reemplazarse las MIP 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 MIP.
**MIP0c7: Modelos de las MIP**
Define los modelos para las MIP generales y técnicas.
**MIP0c8: Dependencias de roles de dominio de MIP0**
Define los roles centrales necesarios para la operación exitosa de las MIP.
**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 Governance Facilitator**
Un componente que define las responsabilidades, los criterios y los causales de remoción del rol de Governance Facilitator.
**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 Governance Facilitator.
**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 Governance Facilitator.
## 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 Maker Improvement Proposals (MIPs).
El propósito del framework de MIP es posibilitar que cualquier miembro de la comunidad pueda hacer su aporte para la mejora de Maker Governance 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 MIP 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 Framework de Maker Improvement Proposal.
## Especificación / Detalles de las propuestas
### MIP0c1: Definiciones del Framework de Maker Improvement Proposal
- **Maker Improvement Proposals (MIPs):** son el mecanismo preferente para la mejora de Maker Governance y del Maker Protocol. 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 Maker Protocol. Una propuesta define claramente cómo y por qué Maker Governance o el Maker Protocol 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 framework MIP. Este MIP define todos los procesos necesarios para la implementación de futuros MIP.
- **Conjunto de MIP:** Un conjunto de MIP es un grupo de varios MIP interdependientes de tal manera que sin la totalidad de los MIP considerados uno o más MIP del conjunto se vuelven inconsistentes, inválidos o absurdos. La intención es que los conjuntos de MIP 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 MIP están separadas según tipo y cada tipo tiene su propia lista de MIP y de procesos.
- **MIP de Proceso:** Las MIP de Proceso se usan para crear y definir un proceso recurrente específico que será empleado por el Protocolo Maker o por Governance.
- **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)
- **Periodo Mínimo de Feedback:** La cantidad mínima de tiempo dentro del cual la comunidad puede dar feedback en respuesta a un MIP.
- **Periodo mínimo de Congelamiento:** La cantidad mínima de tiempo que un MIP debe permanecer sin cambios (congelado) antes de poder ser presentado para su ratificación/implementación.
- **Governance Facilitator(s):** Governance Facilitators 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 signals gathering 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 Maker Foundation y que otras personas se unan más tarde.
- **Domain Teams**: Los Domain Teams trabajan para el DAO, son incorporados a través de la gobernación y costeados por el Protocolo. Los Domain Teams 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 de Risk, Oracles, Smart Contracts 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 MIP 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 solo una parte específica de un todo mayor.
- Esto es importante para la inteligibilidad, la legibilidad y la accesibilidad de las MIP.
3. **Evitar la superposición:** El mismo comportamiento no debería ser implementado independientemente por múltiples MIP. Por ejemplo, no debería haber dos maneras distintas e intercambiables de hacer collateral onboarding.
- 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 MIP 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 MIP y los Estados de las MIP**
![mip_life_cycle](https://user-images.githubusercontent.com/32653033/79086728-19d93900-7d0b-11ea-8086-c255d919096c.png)
**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 MIP deben ser originales o reemplazos de MIP 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/a MIP Editor(s).
**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 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 (Formal Submission)**: 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. "got bundled" (?) en una encuesta de Gobernanza o en un voto ejecutivo con una propuesta pólemica - sujeto al juicio de los Governance Facilitators)
**6. Aprobado por lo/a/s Governance Facilitator(s):** En esta fase, la MIP debe ser formalmente aprobada por un/a Governance Facilitator.
- Una vez aprobada por el/la Governance Facilitator, la MIP estará incluída en la encuesta de inclusión del ciclo de Gobernanza.
- Si la MIP no es aprobada por el/la Governance Facilitator, 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 sera incluída 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 MIP Editor(s) y las partes respectivas. Si el autor original de la MIP no está más disponible, el MIP Editor puede proceder con el transferimiento 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 requerido por el autor de una MIP y será revisado por el/los Editores de MIPs para evaluar si cumple con el criterio del estado
A status change for a MIP is requested by the MIP Author and will be reviewed by the MIP Editor(s) to see if it meets the status criteria of the requested status change. If it does, the Editor(s) will change the status of the MIP and the Author may proceed with the next stage of the process. If it does not, the MIP Editor(s) will revert with highlighted issues, and the Author must fix the highlighted issues before requesting another status change.
### MIP0c4: MIP Components and MIP Component Types
**MIP Components**
- When necessary, MIPs can have multiple components if it needs to contain multiple units of logic to satisfy completeness. A MIP can also have only a single component.
- MIP components are categorized by types, depending on what kind of logic they contain. MIP components are named by their parent MIP. The abbreviation convention MIPXcY is used to refer to these components (as seen in this document).
- A MIP component has one type or no types.
**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 adope 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 traceable. Una MIP de Proceso proveerá un ámbito públicamente documentado del framework 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 framework 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 MIP 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](General-MIP-Template.md)**. Este modelo se considerará ratificado una vez que el estado de este MIP sea *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 smart contract dentro del Protocolo Maker.
- El Modelo de MIP Técnica se encuentra en **[Technical-MIP-Template.md](Technical-MIP-Template.md)**. Este modelo se considerará ratificado una vez que el estado de este MIP sea *Aceptado*.
---
### MIP0c8: MIP0 Dependencias de Roles de Dominio
El framework 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 una editora provisional de la Maker Foundation y que otras personas se unan más tarde.
- **Autoridad específica de la Editora de MIP en los procesos MIP0:**
- El Editor de MIP controla la fase 2 del ciclo de vida de las MIP y tiene la potestad de asignar números MIP
- La Editora de MIP es admin en el repositorio de MIP de Github
- El Editor de MIP es moderador en el foro MIPs Discourse
- La Editora de MIP es responsable de la actualización del estado de las MIP, según se describe en MIP0c4 “El Ciclo de Vida de las MIP”.
- **Governance Facilitator:** Gestiona frontends de votación, lleva a efecto reuniones de gobernanza y acepta MIP 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 todas las Facilitadoras de Gobernanza controla la fase 6 del ciclo de vida de las MIP; esto les permite, consensuadamente, añadir MIP 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:**
- **Nombre de la persona:** Richard Brown
- **Número de Subpropuesta (MIP0c12-SP):** N/A (El Facilitador de Gobernanza fue ratificado con anterioridad al proceso de MIP. Referencia: [Mandate: Interim Governance Facilitators](https://forum.makerdao.com/t/mandate-interim-governance-facilitators/264))
- **Rol Central:** Facilitador de Gobernanza
- **Fecha de Adición:** 2019-09-09 ([Poll: Ratify the Interim Governance Facilitator Mandate](https://vote.makerdao.com/polling-proposal/qmvh4z3l5ymqgtfs6tifq3jpjx5mxgdfnjy6alewnwwvba))
- **Nombre de la persona:** LongForWisdom
- **Número de Subpropuesta (MIP0c12-SP):** 2
- **Rol Central:** Facilitador de Gobernanza
- **Fecha de Adición:** 2020-05-28 [Ratification Vote: Officially Ratify the MIP0c12-SP2 Subproposal for Onboarding a Second Governance Facilitator](https://mkrgov.science/executive/0x9713187b6d7c8d54ac041efdbac13d52c2120fb9)
2. **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](https://vote.makerdao.com/executive-proposal/lower-usdc-sf-add-wbtc-ratify-the-initial-mips-and-subproposals))
---
### MIP0c10: Rol de Editor de MIP
**Responsabilidades**
La Editora de MIP controla los aspectos administrativos y editoriales generales del proceso MIP y de su framework. 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 MIP.
- Asignar a las MIP propuestas sus números de identificación formales.
- Cambiar los estados de las MIP.
- Corregir el posicionamiento categórico de las MIP.
- Mantener comunicación con coordinadores o autores de MIP.
- Revisar las MIP 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 MIP y el ciclo de gobernanza.
**Criterios de selección**
Al seleccionar una Editora de MIP deberían considerarse estos criterios:
- Una comprensión cabal del framework de MIP
- Aunque habrá un transvase de conocimiento al momento de la incorporación, la candidata debe estar muy familiarizada con el framework y con la operación general de otros frameworks 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
- Merging, editing, closing de Pull Requests [no sé si tiene sentido traducir estos términos]
- Hacerse cargo de problemas
- Añadir tags/labels
- Experiencia con el lenguaje Markdown
- Las MIP 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 de riesgo semanales desde una posición neutral.
- Es necesario que organice y lleve a cabo procesos de gobernanza según lo indicado por las MIP 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 MIP 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 Framework Científico de Gobernanza y Riesgo y los Principios (¿"Principals" es un error?)
- 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ían 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 los communications entre otros actores jerárquicos o encargados en el Protocolo Maker.
- Debería estar atentos 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 Framework 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 compartirá conocimiento (? "impartirá" tal vez?) 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](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](MIP0c13-Subproposal-Template.md)**. Este modelo se considerará ratificado una vez el estado de esta MIP pase a *Aceptado*.
---