Porque lo que no se documenta, no existe (y nadie lo va a adivinar por ciencia infusa), aquí te dejamos los lineamientos básicos para mantener esta Wiki organizada, útil y —con suerte— comprensible incluso para los nuevos del equipo.

🎯 Propósito de la Wiki

La Wiki es nuestro repositorio central de conocimiento. Aquí se documenta TODO lo necesario para la ejecución de proyectos, procesos internos, decisiones tomadas (aunque hayan sido con café en mano), configuraciones técnicas y cualquier otra cosa que pueda ayudar a evitar la frase “¿Quién fue el genio que hizo esto?”.

📐 Estructura recomendada

Para no terminar con una wiki tipo archivo de los X-Men (llena de misterios y sin orden), sigue esta estructura:

1. Título claro y conciso: Nada de "cosita-final-v3-bueno-este-sí".

2. Resumen inicial: Dos o tres líneas que expliquen de qué va el documento.

3. Contenido organizado por secciones: Usa encabezados, listas y tablas si hace falta. El caos no es estético.

4. Fecha y autor: Porque el conocimiento tiene contexto.

5. Referencias cruzadas: Si hay otro documento relacionado, enlázalo. No dejes cabos sueltos.

🧠 Buenas prácticas

• Sé claro y directo: Esto no es una novela. No adornes, no divagues.

• Escribe pensando en quien viene detrás: Sí, incluso ese nuevo que entra en seis meses y no tiene ni idea.

• Evita siglas sin explicación: Solo tú y Dios saben qué significa "TPSR-G".

• Actualiza cuando sea necesario: Si algo cambió, refleja el cambio. La Wiki no es una cápsula del tiempo.

🚫 Lo que NO deberías hacer

• Escribir en mayúsculas como si estuvieras gritando.

• Subir archivos sin explicar qué son (¡no somos adivinos!).

• Dejar notas tipo “pendiente por revisar”... y olvidarte por tres años.

• Usar jerga interna que nadie fuera de tu grupo entiende (esto no es Hogwarts).

Donde Organizarlo

🔧 Área Técnica

Aquí va todo lo que requiera más de una línea de código, o que implique tocar la base de datos sin llorar después:

• Cómo está estructurado el módulo de localización.

• Modelos personalizados y campos agregados.

• Reglas contables automatizadas vía código.

• Scripts de instalación o configuración.

• Configuración de dependencias técnicas.

• Ajustes en los templates o reportes (PDF, QWeb, etc).

• Versiones soportadas y cambios entre versiones (ej: diferencias de localización entre Odoo 14 vs 16).

🧩 Área de Consultoría

Aquí entra todo lo que necesita entender alguien que usa el sistema, no lo programa. O sea, el consultor que no se quiere lanzar a leer código para entender qué botón hace qué:

• Manuales de configuración paso a paso (como configurar impuestos, retenciones, libros fiscales).

• Explicación de flujos legales locales (ej: cómo se refleja una retención de ISLR en la factura).

• Buenas prácticas para usar la localización.

• Casos de uso funcionales para el cliente.

• Requisitos legales que cubre el módulo (y cómo lo hace).

• Preguntas frecuentes del cliente (tipo: “¿Dónde veo el libro de compras?”).

🧠 Pro tip:

Si el documento requiere terminal, XML, o tocar el código, va en Técnico.
Si el documento requiere saber qué botón presionar o cómo configurar algo desde la interfaz, va en Consultoría.
Y si tiene de ambos... ¡pues se parte en dos! Un documento técnico y uno funcional, cada uno en su casilla.