Guía para Colaboradores: El Protocolo de Baja Fricción

El Manifiesto Fractal necesita la inteligencia de múltiples disciplinas. Nuestro objetivo es que la tecnología facilite la contribución, no que la obstaculice. Por eso, proponemos un Protocolo de Contribución Coherente que solo requiere un navegador web.

Por qué Git: La Arquitectura de la Coherencia

Podríamos escribir el Manifiesto en un documento de Google o Word, pero esas herramientas están diseñadas para la centralización y la edición lineal. El Manifiesto Fractal exige una arquitectura que refleje sus valores. Git y GitHub (la infraestructura que aloja nuestro Manifiesto) no son solo mejores para trabajar en equipo; son el Protocolo de Soberanía adecuado.

Git opera bajo tres principios fundamentales que reflejan la ontología fractal:

El Principio de Inmutabilidad: Git registra cada cambio como un snapshot inmutable, esencial para la supervivencia del texto. Si algo se rompe, siempre se puede volver a cualquier estado anterior.
El Principio de Soberanía: Cada colaborador tiene una copia propia e independiente del texto mediante el fork (bifurcación). Su trabajo está aislado y bajo su control completo.
El Principio de Modularidad: La única forma de fusionar cambios es a través de una revisión formal (Pull Request), asegurando que las contribuciones sean coherentes y modulares.

La arquitectura de Git garantiza que el texto no se convierta en una posesión central, sino en un patrón que se replica y se sostiene por consenso. Cuando usted bifurca el Manifiesto, esa copia es totalmente suya. Nadie puede editarla, borrarla o reclamar control sobre ella. Si quiere llevar el texto a una “vereda diferente”, en lugar de integrarla a la versión de la que usted partió, es totalmente libre de hacerlo en su fork. NomosFractal solo es dueño de su propia copia.

El poder no reside en un solo archivo, sino en la multiplicidad de copias y en la coherencia del repositorio principal, que actúa como el atractor al que la gente decide adherirse. Es la herramienta perfecta para materializar la consigna central: el poder de la palabra, ostentado por nadie.

Protocolo de Baja Fricción: Cómo Contribuir (Vía Web)

El protocolo de contribución se realiza completamente a través del navegador, sin necesidad de comandos complejos.

Paso 1: Creación de una Cuenta en GitHub

Vaya a github.com y haga clic en “Sign up”.
Elija un nombre de usuario y una contraseña segura.
Seleccione el plan gratuito.

Resultado: Su cuenta de GitHub es su identidad digital en este protocolo.

Paso 2: El Protocolo del Fork (Bifurcación)

El fork es una copia personal que garantiza el aislamiento de su trabajo.

Vaya al repositorio principal del Manifiesto Fractal.
En la esquina superior derecha, haga clic en el botón “Fork” (SU-USUARIO/dialectica-micro-fractal),
Acepte las opciones por defecto y haga clic en “Create fork”.

Resultado: Ahora tiene una copia exacta del Manifiesto en su propia cuenta.

Paso 3: Creación de la Rama (Aislamiento Fractal)

La Rama (Branch) es su mesa de trabajo aislada. Nunca trabaje directamente en la rama principal (main).

Asegúrese de estar en la página principal de su fork.
Localice el menú desplegable de ramas (donde dice main).
Escriba un nombre nuevo y descriptivo para su colaboración.
Haga clic en “Create branch”.

Resultado: Ahora está en su rama de trabajo aislada. Cualquier edición o archivo nuevo que cree solo existirá en esta rama.

Paso 4: Creación y Edición de Contenido

El formato del Manifiesto es Markdown, un lenguaje de texto plano que usa símbolos para dar formato (ej., # para títulos, ** para negritas).

Opción A: Editores Externos WYSIWYG (Recomendado para Borradores)

Para los colaboradores que prefieren ver el formato mientras escriben (lo que se conoce como What You See Is What You Get o WYSIWYG), recomendamos redactar su borrador en editores externos antes de pegarlo en GitHub.

StackEdit: Herramienta gratuita y completa
Markdown Live Preview: Opción sencilla y rápida

Opción B: Edición Directa en GitHub

Para editar o crear un archivo directamente en su rama:

Navegación: Vaya a su rama de trabajo.
Archivo nuevo: Haga clic en “Add file” → “Create new file”.
Archivo existente: Navegue hasta el archivo y haga clic en el ícono de lápiz.

El editor web de GitHub tiene dos modos esenciales:

Modo de Edición (Pestaña “Edit”): Donde escribe su texto Markdown
Modo de Vista Previa (Pestaña “Preview”): Donde verifica cómo se verá su texto publicado

Siempre verifique aquí la coherencia del formato antes de guardar el archivo.

Reglas de Contribución para Mantener la Coherencia

Para actualizaciones: Entregue la versión completa y final del capítulo, reemplazando el contenido antiguo.

Para capítulos nuevos:

Cree un archivo nuevo siguiendo el esquema XX.X_nombre_capitulo.md (ej., 17.5_tecnologia_de_limites.md).
Incluya el encabezado YAML con título y posición sugerida:

---
title: "Tecnología de Límites"
parent: "Versión en Español"
nav_order: 17.5 # <--- Sugiere que va entre el 17 y el 18
---

# 17.5 Tecnología de Límites
....

---

Reconocimiento Opcional (Modulación de la Identidad)

De manera opcional, puede modificar el archivo docs/es/99.9_agradecimientos_y_colaboradores.md. En este archivo usted puede agregar su nombre, apodo, afiliación, datos de contacto y cualquier otra información que considere relevante. Esta colaboración será parte de las modificaciones a evaluar en el Pull Request. Hay que notar, que GitHub ya lleva registro preciso de todas las colaboraciones.

Paso 5: Creación del Pull Request (El Llamado del Atractor)

El Pull Request (PR) es el protocolo por el cual usted propone que su trabajo aislado sea fusionado con el repositorio principal. Es el punto donde el aislamiento se convierte en convergencia.

Es fundamental entender que el PR no es un proceso obligatorio:

Ruta Primaria (Convergencia): El PR es el método ideal si usted cree que su contribución mejora el Manifiesto y debe ser parte de la versión oficial. Su propuesta será revisada por NomosFractal para garantizar la coherencia del Manifiesto completo.
Ruta Alternativa (Soberanía): Si usted desea explorar una ruta completamente diferente (por ejemplo, invertir la lógica fractal, cambiar el enfoque), es libre de no enviar el PR. Su fork seguirá su propio camino, manteniendo su total soberanía. Su versión es un proyecto independiente y autónomo.

El Poder del Atractor: Incluso si su versión sigue un camino distinto, la arquitectura de Git le permite intentar atraer todo el proyecto a su nueva versión. Si su propuesta alternativa es más potente, coherente o mejor que la original, la gente migrará a su fork, convirtiéndolo en el nuevo centro de gravedad (el Atractor más fuerte).

B. Proceso Técnico de Creación del PR

Una vez que ha terminado de hacer commit a su rama de trabajo (feature/...), GitHub le avisará automáticamente que tiene cambios listos para ser propuestos:

Vaya a la página principal de su fork. Verá un gran aviso que dice que su rama (feature/capitulo-X) está adelantada.
Haga clic en el botón verde “Contribute” y luego en “Open pull request”.
Confirme que está proponiendo fusionar desde su rama hacia el repositorio principal.
Use un título claro y una descripción que explique por qué su contribución es coherente.
Haga clic en “Create pull request”.

Paso 6: Resultados del Pull Request y la Disciplina de la Sincronización

Una vez enviado el PR, el repositorio principal lo revisará.

A. Propuesta Aceptada (Fusión)

Si su contribución es coherente con el Manifiesto, será fusionada con la versión oficial.

Su Acción: Sincronice inmediatamente la rama main de su fork con el repositorio principal para tener la versión más actualizada.

B. Propuesta Rechazada (Cierre)

Si la contribución es incoherente con los principios del Manifiesto, el PR será cerrado sin fusión.

Su Acción: Su trabajo permanece intacto en su rama aislada. Puede modificarlo y reenviarlo, o simplemente dejarlo en su fork como un camino alternativo soberano, si desea que su versión siga una ruta diferente.

C. Conflicto de Fusión (Necesidad de Coherencia)

Si otros autores modificaron las mismas líneas de texto que usted antes de que su PR fuera revisado, se generará un Conflicto de Fusión.

Su Acción: GitHub le avisará. No es un error grave, pero significa que debe sincronizar su rama y resolver manualmente las inconsistencias antes de que la fusión sea posible. Esto es un requisito de coherencia: dos ideas no pueden ocupar el mismo espacio al mismo tiempo.