Guía de colaboración del proyecto OrejanOS

Guía de colaboración y filosofía de contribuciones del proyecto OrejanOS (y de proyectos en general de Entropía binaria).

¡Hola! Si estás acá con ganas de aportar, te doy la bienvenida.

Crear software en comunidad es infinitamente más valioso y enriquecedor que construir en solitario. Trabajar en equipo es un placer, y este proyecto existe y crece gracias al impulso del software libre y de la comunidad que lo sostiene.
Sin embargo, para que este espacio sea sostenible y para que yo pueda mantener más de 60 proyectos activos sin quemarme, necesitamos acordar las reglas de colaboración desde el primer momento.

Mi visión sobre la ayuda.

Partamos de una premisa simple: la ayuda tiene que sumar, no complicar. Si una colaboración exige una carga mental abrumadora para ser auditada o genera estrés en el mantenedor, deja de ser ayuda para esa persona.
Esto no es por soberbia ni por rechazo a otras formas de trabajar. Simplemente reconozco mis propios límites cognitivos: no pertenezco ni deseo encajar en el flujo de trabajo tradicional basado en la burocracia de Git. Revisar pull requests, merges, diffs o patches que potencialmente alteran múltiples archivos al mismo tiempo me genera un ruido y una ansiedad innecesarios.
Por eso, este proyecto se gestiona mediante un modelo de colaboración modular e integrada, diseñado para que colaborar sea claro, concreto y predecible para todos.

Cómo colaborar (estos aportes son bienvenidos y se agradecen de corazón).

Acepto con gusto y gratitud cualquier aporte que mantenga un límite claro de impacto y no requiera auditar metainformación ruidosa.

• Módulos enteros aislados: si construís una funcionalidad o módulo completo listo para anexar al proyecto (tipo "plugin" o componente), bienvenido sea. Sé exactamente lo que hace y cómo se conecta.
• Funciones aisladas: código nuevo, cerrado y encapsulado (por ejemplo, una función específica que resuelva un problema puntual).
• Reescritura de funciones específicas: si detectás una función mal optimizada o mal escrita y me alcanzás la versión corregida de esa función concreta.
• Reportes de errores precisos y visuales: descripciones claras de bugs ("al presionar Z en el menú X, el programa se cierra") o capturas/pasos exactos para reproducir un comportamiento.

Cómo NO colaborar.

Para proteger el ritmo del proyecto y la tranquilidad de quien lo mantiene, no se procesará lo siguiente.

• Pull Requests (PRs), Merge Requests o parches tradicionales.
• Cambios que toquen múltiples archivos en simultáneo o alteren la estructura global.
• Diffs o revisiones que requieran auditar metadatos de control de versiones.

Un puente para todos.

Exigir el dominio y el uso de flujos complejos de control de versiones a menudo deja afuera a muchísima gente que sabe programar y que quiere y puede dar una mano. Este modelo busca abrir la puerta a aportes directos, prácticos y modulares.
Si querés colaborar dentro de este esquema, tu código y tu tiempo van a ser enormemente valorados.

¡Gracias por respetar la casa, comprender, cuidar la energía de quienes mantenemos esto vivo y ser parte del software libre que cada día ebulliciona y viene con efervescencia en Entropía binaria!