Contribute to Dweve AI Infrastructure

Puestos a tiempo completo en ingeniería y producto. Trabajo remoto prioritario dentro de la UE.

Pregunta qué ruta de proyecto, licencia y condiciones de contribución se aplican antes de enviar tu trabajo.

Notas de versión, análisis en profundidad y autopsias honestas del equipo.

Referencias de API, guías de integración y documentación de arquitectura.

Los fundamentos técnicos de Dweve, desde Numerus y BitWeave hasta Lattice y AION. Consulta la ruta de acceso de cada proyecto antes de empezar.

Una vez que un proyecto se ha publicado, sigue las instrucciones de su repositorio para proponer un pull request. Antes de eso, la página del proyecto indica su ronda y las condiciones explican la ruta de revisión. Puedes preguntar al respecto en cualquier momento.

Los cambios aceptados se fusionan según la política del proyecto.

Ejecuta las comprobaciones de CI que el proyecto documenta para este cambio.

Se aplican las comprobaciones documentadas.

Aborda los comentarios y sigue las reglas de aprobación del proyecto.

Abre un pull request cuando el proyecto lo acepte, menciona el issue si es necesario y completa su plantilla.

Ejecuta las pruebas y comprobaciones de calidad documentadas por el proyecto antes de abrir un pull request.

Ejecuta comprobaciones de calidad localmente.

Firma los commits y sigue el formato de commit solo cuando el proyecto lo requiera.

Sigue las reglas de commit del proyecto.

Crea una rama según las instrucciones de nomenclatura del proyecto.

Si el proyecto es público y acepta cambios, crea un fork como describen sus instrucciones.

Cada paso tiene una expectativa clara. Usa las comprobaciones de calidad que documenta el proyecto.

Desde la solicitud de acceso o el fork hasta la revisión.

Los proyectos públicos pueden usar un flujo de trabajo de fork y pull request de GitHub. Consulta las instrucciones de cada proyecto para nombres de ramas, firma de commits, referencias a issues, pasos de revisión y expectativas de respuesta.

Acceso, rama, revisión, fusión. Cada proyecto documenta su ruta.

Sigue los requisitos de documentación del proyecto para APIs públicas, ejemplos y guías más largas. Añade suficiente contexto para que otro colaborador entienda y verifique el cambio.

Para cambios sensibles al rendimiento, incluye contexto de benchmarks cuando el proyecto lo pida. Registra el método, la línea base, el hardware y el resultado observado para que un revisor pueda interpretar la afirmación.

Añade pruebas apropiadas al cambio y sigue las comprobaciones del proyecto para pruebas unitarias, de integración, basadas en propiedades o fuzzing. Describe cualquier limitación de cobertura o entorno que afecte a la revisión.

Pruebas unitarias, de integración y de propiedades.

Controles de calidad documentados para el proyecto y el cambio.

Una contribución debe incluir evidencia que corresponda a su cambio. Sigue las pruebas documentadas del proyecto, las expectativas de referencia y los requisitos de documentación; varían según el proyecto y la vía de acceso.

Usa las comprobaciones de pruebas, referencia y documentación que exige el proyecto.

Para el desarrollo nativo, usa las dependencias del sistema y las plataformas documentadas por el proyecto. Algunos proyectos ofrecen instrucciones en BUILD.md; revísalas antes de empezar.

Cuando un proyecto ofrezca un flujo de trabajo con contenedores, sigue sus instrucciones de Docker o Podman y usa la imagen y los comandos que documente. No des por hecho que el contenedor coincide con CI sin comprobar el registro del proyecto.

Si el proyecto usa Rust, instala el conjunto de herramientas y los componentes indicados en sus instrucciones de compilación. Requisitos como rustfmt, clippy, miri o un MSRV dependen del proyecto.

Formas de preparar un entorno de desarrollo. Consulta las instrucciones del proyecto para conocer la vía admitida.

Conjunto de herramientas, contenedores y configuración nativa.

La vía estándar depende del proyecto. Lee sus instrucciones de acceso y compilación, prepara el entorno documentado, ejecuta las comprobaciones que correspondan y usa la ruta de revisión indicada.

Muchos proyectos de Dweve usan Rust, pero los conjuntos de herramientas, las versiones mínimas, los contenedores y los objetivos de integración dependen del proyecto. Usa la documentación actual del proyecto como fuente de verdad.

Conjunto de herramientas de Rust, Docker y configuración local cuando esté documentado.

Revisión del mantenedor cuando sea necesaria

Pruebas del proyecto, Miri y comprobaciones de fuzzing

Conjunto de herramientas de Rust, formato y comprobaciones de lint

Dweve mantiene catorce bases técnicas que abarcan matemáticas, análisis sintáctico, recuperación, políticas, simulación y verificación en tiempo de ejecución. HEDL es público en GitHub; el resto se publica en rondas quincenales a partir del 1 de septiembre de 2026, de dos en dos para empezar. Comienza con la licencia de cada proyecto y la ruta indicada antes de enviar trabajo.

Explora las páginas de las bases. HEDL ya es público, AION y Knot se publican el 1 de septiembre de 2026, y cada una de las demás páginas indica la ronda en la que se encuentra. La ruta del proyecto explica cómo pedir ayuda.

Las contribuciones aceptadas pueden aparecer en las notas de la versión o en un registro de contribuyentes cuando el proyecto lo mantenga. Consulta los términos del proyecto sobre cualquier reconocimiento u otro beneficio.

Reconocimiento en el registro del proyecto.

Las sesiones para contribuyentes pueden anunciarse cuando un proyecto las programe. Consulta la página del proyecto o contacta con Dweve para conocer las opciones de participación actuales; la ubicación, el horario y el apoyo dependen del evento.

Puedes pedir orientación para contribuir a través del proyecto o de la vía de contacto. Que un mantenedor pueda revisar un primer cambio, qué idioma está disponible y con qué rapidez responde alguien dependen del proyecto y de la capacidad actual.

La orientación del proyecto, las sesiones comunitarias y los registros de contribuciones dependen de la ruta que elijas.

Orientación, sesiones y registros del proyecto.

Contribuir puede resultar intimidante. Empieza con una pregunta concreta, un informe, un cambio de documentación o una prueba. Si un repositorio expone plantillas de incidencias o un punto de entrada, úsalo; de lo contrario, solicita la ruta actual a través de Dweve. El apoyo y el tiempo de respuesta dependen del proyecto.

Las prácticas de revisión dependen del proyecto. Lee sus términos de contribución para saber quién puede revisar un cambio, qué comprobaciones se aplican, cómo se gestionan los problemas de seguridad y si el debate es público.

Revisión del mantenedor cuando sea necesaria.

Consulta la licencia y los términos de acceso al código fuente de cada proyecto antes de integrar o enviar trabajo. Si no están indicados, contacta con Dweve antes de usarlo.

Condiciones de licencia y acceso por proyecto.

Las condiciones de contribución varían según el proyecto. Consulta el repositorio o la vía de contacto para conocer la licencia aplicable, las condiciones de revisión y cualquier acuerdo solicitado antes de enviar tu trabajo.

Las condiciones de contribución, la licencia y la revisión varían según el proyecto.

Condiciones de contribución, licencia y revisión.

La contribución necesita condiciones claras. Dweve describe la vía de acceso, licencia y revisión actual de cada proyecto. Los repositorios se publican en rondas quincenales a partir del 1 de septiembre de 2026, así que consulta el registro del proyecto antes de invertir tiempo o enviar trabajo.

Condiciones claras. Vía documentada. Responsabilidad compartida.

Diseño de interfaces, auditorías de accesibilidad, iconografía y recursos de marca. Los diseñadores pueden proponer trabajo para Fabric, el sitio de documentación y las superficies del proyecto. Sigue las pautas de marca y accesibilidad disponibles y pregunta antes de reutilizar archivos o tokens.

Pruebas manuales, ampliación de pruebas automatizadas, pruebas de fuzzing y evaluación comparativa. Los evaluadores verifican que los nuevos lanzamientos funcionan en hardware real y en flujos de trabajo reales. Los evaluadores de fuzzing encuentran casos límite que la lógica determinista debería manejar. Los evaluadores comparativos validan las afirmaciones de rendimiento. Esta vía es ideal para personas metódicas que disfrutan rompiendo cosas.

Referencias de API, guías de usuario, tutoriales y traducción. Los redactores técnicos pueden proponer mejoras a través de la vía documentada del proyecto, y la mayoría de las tareas de documentación no requieren programación. Consulta el proyecto para conocer sus herramientas y su proceso de revisión.

Corrección de errores, mejoras de rendimiento, nuevas funciones y refactorización. Varias fundaciones usan Rust, con otros lenguajes donde el proyecto los necesita. Sigue las instrucciones de acceso al código, revisión y pruebas del proyecto; los puntos de entrada públicos no están garantizados.

Ingeniería de software, documentación, garantía de calidad y diseño. La vía de proyecto disponible y el punto de contacto varían según la fundación.