Comunicación

Dónde hacer preguntas, reportar errores, proponer características y contactar al equipo.

Si solo quieres hablar con nosotros, Discord es la respuesta. Para cualquier cosa que requiera un registro duradero (informes de errores, solicitudes de funciones, discusiones de diseño, RFCs), GitHub.

Discord: el mejor lugar para contactar al equipo

Chat en tiempo real. Aquí es donde los mantenedores están presentes día a día; la vía más rápida para obtener una respuesta humana.

Canales:

• #general: la sala predeterminada
• #help: hilos de “No logro que X funcione”; la forma más rápida de desbloquearte
• #dev: discusión de desarrollo en curso
• #releases: anuncios, notas de la versión, avisos previos de cambios incompatibles

Enlace de invitación en el README del repositorio.

Discord es efímero: si la conversación deriva en un error o una idea de funcionalidad, captúralo después como una issue de GitHub para que el registro persista. Discord es para conversar; GitHub es para la memoria.

Usa un handoff de GitHub cuando Discord produzca algo que el proyecto deba recordar. Crea o actualiza un issue, una discussion, un comentario de PR o un documento de mantenimiento cuando el hilo produzca un bug reproducible, un alcance de funcionalidad concreto, una decisión de arquitectura o gobernanza, un compromiso de mantenimiento, una asignación de owner, una decisión de milestone, un blocker, una solución alternativa, evidencia de validación, una nota de impacto en el release o un motivo de exención por inactividad. El handoff solo necesita la decisión, la evidencia, el owner cuando exista y el contexto suficiente para que otro mantenedor pueda continuar sin tener que releer el chat.

Problemas de GitHub

Para errores, solicitudes de nuevas funcionalidades y cualquier cosa que deba ser rastreada.

• Informes de errores: use la plantilla de errores (.github/ISSUE_TEMPLATE/bug_report.yml). Incluya zeroclaw --version, el sistema operativo y la salida de zeroclaw doctor.
• Solicitudes de funcionalidades: use la plantilla de funcionalidades (.github/ISSUE_TEMPLATE/feature_request.yml). Céntrese en el valor para el usuario y las restricciones; los detalles de implementación son para los RFC o la discusión en el PR.
• RFCs: consulta el proceso de RFC.

Busca antes de crear un nuevo informe. Los duplicados se consolidan; la caja de búsqueda es tu mejor aliada.

Discusiones de GitHub

Para hilos orientados a la comunidad que necesitan más permanencia que Discord pero que aún no son trabajo en seguimiento. Las discusiones funcionan bien para preguntas y respuestas, ideas, presentación de proyectos, encuestas, anuncios de mantenedores e hilos del tipo «¿alguien más ve esto?» que en Discord se perderían al desplazarse.

Trata las Discussions como conversaciones comunitarias no urgentes. Solo se consideran parte de la recepción mantenida cuando hay un steward documentado o una cadencia de revisión establecida. La rutina del mantenedor y la cadencia predeterminada se encuentran en Reviewer playbook: Discussions stewardship.

Las discusiones forman parte del sistema de transferencia de GitHub, no un reemplazo de las incidencias, los RFC, los comentarios de PR ni la documentación del mantenedor. Mueve una discusión a la superficie con seguimiento una vez que genere un error concreto, un alcance de característica, un propietario, un bloqueador, evidencia de validación, una decisión de política o un requisito de documentación.

Usa esta división al elegir una superficie:

Las categorías de discusión deben dejar claro el resultado esperado. Usa Q&A para preguntas que tengan respuesta, Ideas para propuestas que necesitan moldearse con la comunidad, Show and tell para demos relacionadas con el proyecto, integraciones o forks derivados que la gente quiera compartir, Polls para votaciones de la comunidad, Announcements para actualizaciones de los mantenedores, y General para conversaciones amplias y consultables, exploración temprana de arquitectura, o colaboración derivada/de forks/empresarial que aún no sea trabajo rastreado. Si la colaboración derivada se vuelve lo suficientemente recurrente como para necesitar su propio carril gestionado, los mantenedores pueden añadir una categoría dedicada más adelante.

Cierra el ciclo cuando una Discussion se traslade. Añade un breve resumen y un enlace al issue, RFC, PR o documento que ahora gestiona el resultado. Si la categoría admite respuestas aceptadas, marca el resumen o el enlace al trabajo en seguimiento como la respuesta cuando esto refleje con precisión el resultado.

github.com/zeroclaw-labs/zeroclaw/discussions

Contactos de los mantenedores

Todos los que aparecen a continuación son miembros del Core Team, el rol de Nivel 3 definido en FND-003. La membresía se adquiere mediante invitación y anuncio público, según el §5.1; esta tabla es un resumen publicado de esas decisiones, no el registro que las establece. Es de esperar que difiera del equipo core-contributors de GitHub y de la lista de colaboradores, que son controles de acceso y no registros de membresía: incluyen cuentas de automatización, y el acceso puede ser directo, heredado o pendiente. Consulte el §5.3 para saber qué registro responde a qué pregunta.

La columna Focus describe dónde trabaja cada persona, no cuánta autoridad tiene: Core Team es horizontal. Las decisiones rutinarias se toman por consenso tácito, y los cambios en CODEOWNERS, lanzamientos, resultados de RFC, ediciones de gobernanza y adiciones al Core Team requieren una votación explícita del Core Team independientemente del rol. “Project lead” es un rol de coordinación y escalada dentro del Core Team, no un nivel superior a él.

No todas las personas incluidas revisan código. Dirige la revisión de código según la columna Focus y CODEOWNERS, no según el nivel.

Las áreas de enfoque siguen .github/CODEOWNERS, que es el registro de enrutamiento autoritativo. Esta tabla es el resumen legible por humanos; si ambos discrepan, CODEOWNERS tiene prioridad.

Usa menciones con @- con moderación, solo a los mantenedores de CC cuando el problema realmente necesite su atención. Por defecto, deja que el equipo haga el triaje.

Problemas de seguridad

No presente informes públicos sobre vulnerabilidades de seguridad.

Reporta de forma privada a través del reporte privado de vulnerabilidades de GitHub (Security Advisories).

Incluir:

• Versiones afectadas
• Reproducción (mínima, por favor)
• Evaluación de impacto

Nuestro objetivo es acusar recibo en un plazo de 48 horas, evaluar en 1 semana y publicar una corrección en 2 semanas para los problemas críticos. Se agradece la divulgación coordinada.

Consulta SECURITY.md en la raíz del repositorio para obtener la política completa.

Feed de lanzamientos

Suscríbete al feed de lanzamientos de GitHub para recibir notificaciones cuando se publiquen nuevas versiones:

https://github.com/zeroclaw-labs/zeroclaw/releases.atom

O sigue el repositorio en GitHub (Watch → Personalizado → Lanzamientos).

Las notas de la versión se publican simultáneamente en Discord #releases y en el Twitter de la comunidad.

Soporte comercial

Ninguno ofrecido. ZeroClaw es mantenido por la comunidad. Si estás desplegando a gran escala y deseas SLAs, patrocina a un mantenedor directamente o financia un acuerdo de soporte dedicado a través del equipo principal. Contacta a través de hello@zeroclaw.dev.

Comentarios

Los comentarios abiertos, “intenté hacer X y se sintió mal”, observaciones de UX, ideas sobre la dirección, encajan mejor como un hilo en Discord #general o #dev cuando se necesita una conversación rápida en vivo. Usa GitHub Discussions General o Ideas cuando los comentarios deban permanecer disponibles para búsquedas y para aportes asíncronos de la comunidad. Si el hilo se convierte en algo concreto, muévelo a un issue, RFC, comentario de PR o documento.

Reconocimiento de colaboradores

Todos los que han tenido un PR fusionado aparecen en la lista de colaboradores del repositorio. Para contribuciones sustanciales, funcionalidades, RFCs, correcciones de errores significativas, tu nombre de usuario aparece en las notas de la versión.

Ver también

• Cómo contribuir
• Proceso de RFC
• Filosofía: lo que el proyecto intenta ser, para que sepas qué está dentro del alcance