Skip to content

Latest commit

 

History

History
114 lines (63 loc) · 14.9 KB

builders.md

File metadata and controls

114 lines (63 loc) · 14.9 KB

Participar como OpenRoot builder

Tú eliges qué construir. Se puede considerar cualquier categoría de software si es legal, segura de alojar, respeta derechos ajenos y cumple los requisitos publicados de la cohorte.

Trae tus ideas. Se acepta cualquier lenguaje de programación e idioma de repositorio/documentación, incluidos idiomas distintos del inglés. Eliges tecnología, alcance, hoja de ruta y dirección. No es una colección limitada a inglés o IA.

Puedes mantener el repositorio privado durante el desarrollo. Acuerda duración y requisitos de publicación antes de inscribirte en una cohorte financiada. No hay plazos arbitrarios ni publicación automática. Un hito basado en lanzamiento o adopción públicos sigue requiriendo las pruebas acordadas. Otros builders no acceden automáticamente al código privado; los propietarios de la organización conservan administración.

Solicitud y acceso

La solicitud pide correo y usuario GitHub exacto. OpenRoot debe aprobarla. El portal no está abierto a todos; iniciar sesión con Google o correo no evita la aprobación.

Es obligatorio tener cuenta GitHub. Los builders aprobados aceptan una invitación a la organización OpenRoot y crean sus repositorios allí. El sitio https://openroot.dev/apply acepta solicitudes para revisión manual. Enviar no crea una cuenta ni concede acceso. Puedes solicitar revisión de cuentas adicionales, GitHub Apps y equipos. Nunca envíes contraseñas, tokens o claves privadas.

La aprobación crea una cuenta pendiente en el portal y envía un correo con instrucciones. Inicia sesión en https://openroot.dev/portal con el correo aprobado e introduce el código recibido solo en esa página. Kristofer envía manualmente la invitación GitHub antes de aprobar la cuenta del portal. La aprobación envía un único correo de bienvenida con los pasos para aceptar la invitación y crear el repositorio en la organización. La vinculación automática de identidad GitHub, las métricas de proyectos, la inscripción completa y las reclamaciones automáticas de recompensas en el portal todavía no están disponibles. Las cuentas pendientes conservan el plazo original de 90 días de la solicitud. La aprobación por sí sola no concede una recompensa financiada.

Solicitar antes de elegir un proyecto

Marca “Todavía no sé qué voy a construir” si no has elegido proyecto. La nota de intereses es opcional; no tienes que inventar propuesta ni URL de repositorio. Es una solicitud sin proyecto definido para revisión manual, no un proyecto aprobado ni una cohorte con recompensas. Un proyecto concreto y sus hitos aún necesitan aprobación antes de la elegibilidad.

Condiciones de solicitud y políticas publicadas

Antes de enviar, acepta expresamente las Condiciones de Solicitud actuales y las políticas publicadas de builders y recompensas. Esta aceptación es independiente del consentimiento de privacidad. El backend exige y registra la versión actual 2026-10-12-1 y la fecha/hora del envío. Se rechaza aceptación ausente, sin marcar o desactualizada.

Reglas de solicitud:

  • Da información veraz y comparte solo material autorizado. No incluyas credenciales, código privado ni información personal sensible.
  • La solicitud pide revisión manual; no crea cuenta, pertenencia a la organización, acceso a repositorios ni promesa de recompensa. Puedes solicitar sin proyecto elegido.
  • Enviar no transfiere proyectos, derechos de código ni repositorios. Los proyectos aceptados después deben respetar derechos ajenos y políticas publicadas.
  • Aprobación, acceso, hitos, disponibilidad de recompensas y transferencias necesitan revisión separada y condiciones acordadas. Registrarse no implica elegibilidad.
  • Los acuerdos de inscripción, proyecto/salida y recompensas financiadas son separados. Solicitar no acepta condiciones futuras sin publicar ni umbrales sin anunciar.

Privacidad, conservación y solicitudes de corrección/borrado se explican abajo. Preguntas: hello@openroot.dev.

Privacidad de la solicitud

OpenRoot, operado por Kristofer Jussmann, recoge correo, usuario GitHub exacto, propuesta, pruebas opcionales, peticiones de colaboración/acceso, referencias, fuente de descubrimiento opcional y registro de consentimiento para revisión y comunicación relacionada. La fuente declarada voluntariamente ayuda a entender dónde encuentran OpenRoot los builders; no utiliza cookies de seguimiento. No envíes credenciales, código privado ni datos personales sensibles. Incluye otras cuentas solo con permiso.

Los envíos se guardan de forma privada en Google Cloud en Finlandia, accesibles solo a administradores autorizados. Los registros caducan tras 90 días; el borrado automático es asíncrono. Las cuentas aprobadas del portal tendrán condiciones separadas antes de activarse. La infraestructura procesa registros técnicos; el servicio no registra deliberadamente el contenido de las solicitudes en logs.

Solicitar no te suscribe al boletín. Contacta con hello@openroot.dev para acceder, corregir o borrar un envío, o retirar consentimiento. Puede requerirse verificar tu identidad. Enviar no demuestra que controles el correo o la cuenta GitHub indicados.

Tu papel

Los builders desarrollan, atraen usuarios, mantienen sus proyectos y aportan pruebas. OpenRoot ayuda a promocionarlos en su publicación y redes, totalmente gratis y tanto como pueda. No administra todas las campañas ni garantiza cobertura, alcance, reseñas favorables o éxito.

La promoción no se limita a una única publicación. Los proyectos pueden aparecer varias veces en la newsletter y en las redes sociales mediante destacados, presentaciones y artículos en profundidad. Los builders pueden enviar lanzamientos, actualizaciones importantes e historias de usuarios a hello@openroot.dev para su consideración editorial. Este apoyo es totalmente gratuito y no exige obtener ni canjear una recompensa. El momento y el formato dependen de la adecuación editorial y de la capacidad disponible; OpenRoot no garantiza nuevas publicaciones, alcance ni resultados.

Buscamos builders que estén creando o explorando proyectos pensados para que otras personas los utilicen: software que resuelva un problema, ofrezca una herramienta útil o ayude a sus usuarios a hacer algo. Cualquier categoría de software, lenguaje de programación e idioma de documentación es bienvenido. El proyecto no necesita tener usuarios todavía; siguen siendo bienvenidos quienes aún no han elegido una idea y una fase privada de desarrollo acordada.

También son bienvenidos los builders de hackathons, tanto si se preparan para participar como si continúan un proyecto de hackathon. Se están planificando recompensas adicionales por buenos resultados en hackathons elegibles y previamente aprobados. Los eventos elegibles, resultados, pruebas, financiación y condiciones de los bonos deben publicarse y acordarse antes de iniciar una oferta con recompensas. Ganar no concede automáticamente puntos ni recompensas de OpenRoot. Aún no se han anunciado hackathons elegibles concretos ni importes de bonos; las solicitudes de bonos de hackathons aún no están abiertas.

La participación no es exclusiva. Puedes entrar en hackathons, colaborar fuera y realizar otras actividades. Revisa las reglas del evento y las obligaciones de licencia/contribuidores; OpenRoot no exige renunciar a esas oportunidades.

Equipos y roles GitHub delimitan la colaboración. Tener acceso al proyecto no da administración de toda la organización. El portal previsto muestra repositorios asociados, incluidos proyectos de equipo; quien creó el repositorio no es necesariamente el único contribuidor o beneficiario.

Tu proyecto sigue siendo tuyo

La política prevista mantiene tus derechos sobre el código propio y la dirección del proyecto. El repositorio está alojado en la organización OpenRoot y el responsable aprobado recibe Admin a nivel de repositorio. Los propietarios de la organización conservan administración. Admin no implica propiedad personal del espacio GitHub; licencias, salida y transferencia deben acordarse antes de inscribirse.

Proyectos existentes y colaboración

Puedes proponer un repositorio con usuarios, descargas o estrellas. Envía primero la URL y pruebas fechadas; no lo transfieras antes de la revisión. Admisión, transferencia, inscripción y recompensas son decisiones manuales separadas. Las métricas existentes solo cuentan según la referencia y las reglas acordadas, no por entrar en la organización.

Equipos por proyecto pueden abarcar varios repositorios aprobados. Responsables reciben Admin acotado; colaboradores, el rol revisado. Evita escritura global y herencia accidental de equipos superiores. Las cuentas de automatización no son builders independientes premiados.

Antes de inscribirte

Deben explicarse y acordarse derechos, licencia, mantenimiento, salida/transferencia y reparto de recompensas. El acuerdo final sigue preparándose. Entrar en una organización GitHub no resuelve estas cuestiones por sí solo.

La cohorte debe indicar recompensas, capacidad, umbrales, periodo y revisión. Sin estas condiciones, expresar interés no crea derecho a recompensa.

Consulta el proceso y las recompensas.

Referidos

El programa previsto reconoce a builders aprobados que alcancen hitos verificados, no números de registros. La solicitud puede incluir el usuario GitHub exacto de quien recomendó al candidato. Financiación y reglas finales deben publicarse antes de activarlo.

Privacidad de la cuenta pendiente en el portal

Una aprobación revisada crea una cuenta pendiente con correo, usuario GitHub y estado de incorporación. Conserva la fecha original de caducidad de la solicitud, sin ampliar los 90 días de conservación. El acceso utiliza una cookie segura y necesaria de sesión del navegador, que caduca a las ocho horas. Los desafíos de código por correo caducan a los diez minutos; el servicio guarda hashes, no códigos en texto plano. Google Cloud procesa los registros privados de cuenta y revisión; Resend procesa los correos transaccionales de acceso y aprobación. Solo administradores autorizados revisan solicitudes; los builders acceden únicamente a su propia información del portal. No se crea una suscripción a la newsletter, seguimiento publicitario ni invitación GitHub automática. La inscripción completa y la conservación de perfiles activos requieren condiciones separadas. Acceso, corrección o eliminación: hello@openroot.dev.

Proyecto existente: paso a paso

Un proyecto existente aceptado debe alojarse en OpenRootdev. Tras la revisión, transfiere el repositorio original o copia su código a uno nuevo de la organización. Un enlace a un repositorio externo no basta. Para proyectos existentes, estos pasos sustituyen la creación de un proyecto nuevo indicada arriba.

Antes de ambas opciones: envía la URL original, confirma tu autoridad y los derechos de colaboradores/licencia, acuerda la migración con OpenRoot y acepta la invitación. Haz una copia de seguridad y revisa secretos, integraciones y costes de Actions antes de mover o subir código. Si la aprobación o los permisos no están claros, contacta con hello@openroot.dev.

Opción A: transferir el repositorio original

Recomendada para conservar estrellas, issues, pull requests e historial Git.

  • 1. Abre el repositorio original en GitHub y ve a Settings → General → Danger Zone → Transfer. Necesitas Admin del repositorio y permiso para crear repositorios en OpenRootdev; salir de otra organización puede requerir a su propietario.
  • 2. Establece OpenRootdev como nuevo propietario. Comprueba que el nombre esté libre, lee los avisos de GitHub (los repositorios privados pueden perder funciones de planes de pago en GitHub Free), escribe el nombre y confirma.
  • 3. Verifica que la URL empiece por https://github.com/OpenRootdev/. Pide a OpenRoot que compruebe tu Admin del repositorio y los accesos del equipo; los propietarios de la organización conservan acceso administrativo.
  • 4. En cada clon local existente ejecuta git remote set-url origin https://github.com/OpenRootdev/YOUR-REPOSITORY.git. Revisa integraciones, despliegues, Pages, secretos y workflows antes de continuar. No recrees la ruta antigua, porque puede romper las redirecciones.

Opción B: copiar el código a un nuevo repositorio de la organización

Úsala para mantener el original donde está y desarrollar la copia aprobada en OpenRootdev.

  • 1. Abre New repository. Verifica Owner = OpenRootdev, el nombre acordado y la visibilidad pública/privada. No inicialices README, licencia ni .gitignore; crea un repositorio vacío.
  • 2. En la terminal, sustituye los nombres de ejemplo y usa una carpeta local nueva: git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git openroot-project, después cd openroot-project.
  • 3. Añade el destino sin cambiar el remote original: git remote add openroot https://github.com/OpenRootdev/YOUR-REPOSITORY.git.
  • 4. Sube la rama actual: git push openroot HEAD:main. Comprueba los archivos en el repositorio de la organización. Para futuras actualizaciones, sube a openroot, no al origin original. Si el destino no está vacío o se rechaza el push, detente y pide ayuda; no fuerces el push.
  • 5. Se copia el historial de commits alcanzable de la rama elegida, no estrellas, issues, pull requests, releases, ajustes ni todas las ramas/etiquetas. Los objetos Git LFS y submódulos requieren tratamiento aparte; pide ayuda. Conserva los archivos de licencia/atribución y no copies secretos.

Envía a OpenRoot la URL final de la organización para asociarla al proyecto revisado. La adopción previa y las recompensas requieren una base acordada y aprobación separada; no cuentes dos veces los datos de las copias. No elimines el original solo para participar. Conservas los derechos de tu código; alojarlo en la organización no elimina el acceso administrativo de sus propietarios.

Referencias oficiales: transferencia, nuevo repositorio, Git push.

Atribución opcional de afiliado

La versión 2026-10-14-3 de privacidad de solicitudes añade un código de afiliado opcional. Usa un código o el nombre GitHub del recomendante, no ambos. Se guarda privadamente como declaración de atribución y se revisa antes de vincularlo a una cuenta aprobada; no aprueba pertenencia, proyecto ni recompensa. No hay cookies de seguimiento de afiliados ni se revela al afiliado la identidad del solicitante o información privada del proyecto. Tu propia recompensa no se reduce. Los Términos de Solicitud siguen en 2026-10-12-1 y no cambian los consentimientos anteriores. Consulta el piloto independiente de afiliados.