He hecho un par de diagramas que yo espero les den una idea del proceso ques es trabajar localmente para un colaborador frente un mantenedor
Modelo de Repo Comparido
El Modelo de “Shared Repository” (o repo compartido en Español) es normalmente usado en una organización GitHub
Un mantenedor no necesita usar un fork, porque tiene “write permission” (o permiso de escritura en Español) al repo
El mantenedor puede clonar el repo (usando el shared repo URL)
El mantenedor puede realizar sus cambios, probablemente en una branch, y hacer push a los cambios en el repo
El mantenedor puede crear un pull request (directamente en el GitHub Organization)
Modelo Fork y Pull
El Modelo Fork y Pull es normalmente usado en las cuentas del colaborador. Puesto que el colaborador no tiene “write permission”, necesita hacer un fork del repo en su cuenta de usuario, donde el colaborador tiene estos permisos.
El colaborador hace un fork al repo
El colaborador clona el fork (usando el fork URL)
El colaborador puede hacer su cambio, luego submit los cambios al fork (probablemente en una branch)
Crear un Pull Request
Cuando este listo, el colaborador crea el pull request (a la GitHub Organization)
La compare branch debe ser la branch del colaborador.
La base branch debe ser la branch en la que se deben hacer merge a los cambios
El colaborador crea un pull request y luego tal vez una descripción
El colaborador hace clic en “Create Pull Request” (o "Crear Pull Request" en Español)
Revisando un Pull Request
Ahora vamos a cambiar a la perspectiva del mantenedor
Cuando un colaborador crea un pull request, los mantenedores del repo van a recibir una notificación del navegador o correo electrónico para informarles que hay un pull request.
Siga el enlace a la página del pull request en el navegador
Revise la información sobre el pull request. Puedes ver el título y la descripción y hacer clic en el enlace "Files changed" (o “Archivos cambiados” en Español) para ver todos los cambios realizados.
Revisando un Pull Request
Ahora vamos a cambiar a la perspectiva del mantenedor
Cuando un colaborador crea un pull request, los mantenedores del repo van a recibir una notificación del navegador o correo electrónico para informarles que hay un pull request.
Siga el enlace a la página del pull request en el navegador
Revise la información sobre el pull request. Puedes ver el título y la descripción y hacer clic en el enlace "Files changed" (o “Archivos cambiados” en Español) para ver todos los cambios realizados.
Pull Request: Línea Comando
Hay algunos situaciones cuando necesitas hacer fetch una pull request branch en tu entorno de desarrollo local para poder ejecutar el código o ejecutar una test o trabajar en el código para poder hacer merge.
Cuando haces clic en el enlace “command line instructions”, se abrirá un conjunto de instrucciones sobre cómo revisar y (posiblemente) hacer merge al pull request en tu entorno de desarrollo local.
Pull Request: Opciones Si No Ejecutas el Código Localmente
Si no se necesita ningún cambio o el cambio se puede hacer en el navegador
Realice el cambio en el navegador
Haga clic en merge
Pull Request: Opciones Si Ejecutas el Código Localmente
Si no se necesita ningún cambio, vuelve al navegador y haz clic en merge
Si se necesita un cambio, pídale al colaborador que lo haga, o submit mismo la actualización, y luego haga clic en merge
Pull Request: Comandos
Si necesitas ejecutar el código localmente y sigues el conjunto de instrucciones, harás merge manualmente a la pull request branch localmente a la que se pretende merge y push a esa branch en GitHub
Yo no hago eso.
Sólo sigo la parte de las instrucciones en negro para obtener la branch
Yo ignoro las instrucciones en rojo
Si verifico que el cambio puede ser merged, vuelvo a la página de GitHub pull request en el navegador y hago clic en merge
Por un lado, la main branch a menudo puede estar protegida
Además, en el navegador, puedes simplemente pulsar un botón para revertir el pull request
Flujo de Trabajo: GitHub Flow
El flujo de trabajo que hemos estado usando es básicamente GitHub Flow. Consiste en merging pull requests en un main branch.
Flujo de Trabajo: Variación
Algunos proyectos usan ambos main y develop branches.
En esta situación, los desarrolladores hacen un merge de sus trabajo en el dev branch. Eventualmente, el dev branch es merged en el main branch. Si el main branch se despliega, los cambios están activos
Algunas Recomendaciones
Algunas recomendaciones
Licenses
Licencias no copyleft
Licencias Copyleft
Licencias éticas
GitHub “Choose a License” (Elija una Licencia)
Una license muy comun es la MIT license
La MIT License es non-copyleft y da al usuario mucha libertad en el uso del código, incluyendo el hacer el código privado
Una Copyleft License suele exigir que el código siga siendo de código abierto
Por esta razón, los copyleft licenses pueden crear un riesgo del negocio
Las “ethical licenses” (o licencias éticas) son un tema muy interesante en mi opinión
Pero a veces los términos de las “ethical licenses” son difíciles de hacer cumplir
GitHub tiene un excelente recurso llamado “Choose a License” (o Elija una Licencia)
Un aspecto difícil de la seguridad del software es que
El supply chain del software es todo lo que compone su código,
Incluidas el GitHub organization, el proyecto, y las personas que tienen acceso
E incluidas las dependencias y el alojamiento externo
Por ello, un proyecto necesita un plan de seguridad con varias partes
Algunos ejemplos
Para el nivel individual… autenticación de 2 (dos) factores, acceso limitado
Para el nivel de organización… scanning de secretos y dependencias para las vulnerabilidades
Para el nivel de proyecto… nuevas releases que incorporan los últimos parches de seguridad y un plan de seguridad del proyecto con información sobre cómo informar de las vulnerabilidades
CHAOSS: Métricas de Código Abierto para Evaluar la Salud de Tu Proyecto
Si quieres empezar a medir la salud de tu proyecto
Hay métricas especiales
CHAOSS, por ejemplo, es una colección de métricas que puedes utilizar para crear un plan de salud para tu proyecto
https://chaoss.community/metrics/
Más Funciones Útiles de GitHub
Una lista para futuras referencias de más funciones útiles de GitHub
Issue y pull request templates y Global Community Health File Repo
Métodos de Comunicación: Wiki, GitHub Pages/Jekyll
Descubribilidad: labels/triaging, topics, publicaciones de blog
Un Caso de Estudio: Sitio Web de DjangoCon US
Un caso de estudio: Sitio Web de DjangoCon US
Puntos Clave
DjangoCon US Sitio de Web ha estado
Una oportunidad para:
Aprender los fundamentos de manteniendo
Crecer en una comunidad de colaboradores
DjangoCon US: La Conferencia Con Un Corazón
Pasé mucho tiempo mirando a través de GitHub
Me di cuenta que muchas conferencias están buscando voluntarios quien pueden mantener sus sitios web
Entonces, me involucré con DjangoCon US
Esta es una foto de mi con algunos de los otros organizadores
Los Sitios que He Supervisado
Quería llevar mi conocimiento de GitHub a un nivel superior al aprender cómo ser un mantenedor
Entonces yo pregunté la DjangoCon US Chair si podía ser un mantenedor del sitio web
Ella dijo "seguro" y me invitó a ser el web Chair del sitio y yo acepté
Los Pull Requests Más Fácil (sesenta y siete commits, veinte ocho pull requests)
Una de las estrategias que me ayudó a aprender el proceso de mantener el software
El otro mantener me dejó los pull requests más fáciles
Yo aprendí como…
Yo aprendí como…
Hacer fetch a un pull request localmente
Ejecutar el código
Hacer push a una actualización desde un fork a un pull request
Hacer merge a un pull request localmente
Hacer push a un pull request a una main branch
Aumento en el Número de Colaboradores
Porque un sitio web Jekyll es muy fácil de usar
Pude aprender los fundamentos de ser un mantenedor
Y también pudimos aumentar drásticamente el número de colaboradores
De 23 (veinte trés) en 2016 (dos mil dieciséis)
A la 65 (sesenta y cinco) en 2020 (dos mil veinte)
Me Convertí en Mentor
Creé los nuevos documentos colaboradores
Yo ayudé a algunos principiantes a hacer sus primeras contribuciones
Algunas Lecciones Aprendidas del Sitio Web de DjangoCon US
Algunas lecciones aprendidas del Sitio Web de DjangoCon US
Seguridad Psicológica
Es ideal aprender en un ambiente que ofrece seguridad psicológica
Afortunadamente para mí, no podría haberme topado con una comunidad más agradable
Los Errores Desaparecen en el Historial de Git
Está bien tener una mentalidad de principiante; cometer errores, seguir mejorando
La Perspectiva del Principiante es Valiosa
La perspectiva del principiante es valiosa
Es posible que los veteranos del proyecto no pueden verlo con los ojos de un principiante
Un principiante puede mejorar el proyecto para la próxima persona
Por ejemplo: crear docs de instalación
Logrando Resultados 10x (diez veces)
Personas con frecuencia hablan sobre el concepto del 10x (diez veces) resultados
Es importante recordar que algunas de los habilidades que crean el 10x (diez veces), no involucran escribir código
Un pocos ejemplos:
Mantener los docs
Hacerle publicidad al proyecto
Ser mentor de los colaboradores
Mi Primera Charla Tech
Cuando aprendes una nueva habilidad, tienes la oportunidad de enseñar otras personas y impactar al mundo
Después yo aprendí cómo mantener el DjangoCon US sitio web yo cree una charla sobre cómo hacerlo
Es uno de mis objetivos que ayudar otras mujeres ser mantenedores
Yo di la charla llamada “Get a Jumpstart on Collaboration and Code Review in GitHub” por primera vez en DjangoCon US 2017 (dos mil diecisiete)
Un Caso de Estudio: Pinax
Un caso de estudio: Pinax
Vocabulario de Pinax
Yo voy a usar alguno vocabulario especial por el caso de estudio de Pinax
Un Pinax Starter Project es un Proyecto de Inicio de Pinax
Una Pinax app es una aplicación Pinax
El Pinax CLI (Command line interface) es una interfaz de línea de comandos
Los Pinax Themes son Temas Pinax
Vocabulario de Testing
Yo voy a usar alguno vocabulario especial de testing
Test es prueba
Test matrix es matriz de pruebas
Continuous integration es integración continua
Vocabulario de Packaging
Yo voy a usar alguno vocabulario especial de packaging
Package es paquete
Release notes son notas de versión
Tag es etiqueta
Publish es publicar
Puntos Clave
Pinax ha estado
Una oportunidad para:
Mantener una librería compleja de Django
Convertirte en un Python package release manager
Aprenda a lidiar con el síndrome de lavadero
Fui Contratado por Eldarion para Mantener Pinax
En el otoño de 2017 (dos mil diecisiete), según mi experiencia como mantenedor de DjangoCon US 2017 (dos mil diecisiete)
Me contrataron para trabajar en Pinax
Pinax es una librería de código abierto de Starter Projects, apps y temas reutilizables de Django para crear sitios web
Nació Pinax: 2008 (Dos Mil Ocho)
Un poco de historia sobre Pinax
Cuando me contrataron, habían pasado alrededor de 10 (diez) años desde que nació la idea de Pinax
Django había sido de código abierto en 2005 (dos mil cinco)
En marzo de 2008 (dos mil ocho), en PyCon US en Chicago, algunos entusiastas de Django comenzaron trabajando en Pinax
Estaban creando Pinax para resolver su propio problema
Cómo Comenzó
Se encontraron reutilizando algunos de los mismos patrones de código mientras creaban sitios web con Django
Así que comenzaron a abstraer estos patrones en Starter Projects, aplicaciones y temas reutilizables de Django
Ellos querían crear una libreria de desarrollo web reutilizable que hiciera elecciones y compromisos
Esta libreria les permitiría centrarse en las features en la parte superior de la pila
De esa manera, podrían pasar de la idea del sitio web a la realización rápidamente, en lugar de reinventar la rueda
Cómo Comenzó
Entonces, ¿cuál era el estado de Pinax cuando me contrataron?
Es bastante común, desde el principio hasta ahora, que las personas descubran Pinax y digan "es todo lo que siempre soñaron"
En esta diapositiva hay uno de los primeros tweets sobre Pinax ... alguien dice "Pinax es todas las ideas que he tenido"
Cómo Iba, 80 (Ochenta) Proyectos y Apps
En 2017 (dos mil diecisiete), Pinax había crecido hasta convertirse en un gran grupo de proyectos y apps Django de calidad profesional y interdependientes
Incluyendo starter projects con Pinax apps preinstalado y una Pinax CLI para instalarlos
Y tests sofisticadas, packaging y configuraciones de continuous integration
El Pinax GitHub Organización tiene aproximente 80 (ochenta) repos
Esta diapositiva incluye muchas de los más populares
Cómo Iba, Faltaba la Sostenibilidad
Pero ... faltaba la sostenibilidad
Muchos de los autores originales habían seguido adelante
Sin una estrategia para hacer Pinax más facil de mantener, los mantenedores comenzaron a sufrir agotamiento (o burnout en English)
Cómo Iba, GitHub Organización, Global Docs, y Slack
Además de la GitHub Organización Pinax ahora tenía un sitio de global docs y un Pinax Slack canal para comunidad y apoyar
También había docs específicos de la aplicación en repos individuales
Tradicional Proyecto Django
Ahora, yo voy a hablar sobre GitHub y el entorno de desarrollo local y cómo funciona Pinax
En tu entorno de desarrollo local, si estás iniciando un proyecto tradicional de Django...
Necesitarás tener Django instalado y normalmente estarías usando un virtual environment
Ejecutas el comando `` `django-admin startproject``` en la terminal para iniciar un proyecto
El proyecto contiene la configuración global y otras configuraciones para tu sitio web
Los proyecto template archivos creados en el directorio están desde el Django package
Tradicional Django Apps
Luego, ejecutas un comando adicional para agregar una o más aplicaciones a tu proyecto
Cada aplicación contiene una funcionalidad especial (por ejemplo, una aplicación de "blog" para una parte de blog de tu sitio web)
Los aplicación template archivos creados también están desde el Django package
Pinax CLI
Con Pinax, puedes instalar Pinax CLI
Puedes usar comandos para obtener información sobre Pinax (como una lista de starter projects o apps)
Pinax Starter Projects son básicamente proyectos personalizados de Django
Estos ya tienen alguna funcionalidad integrada y cuando usando los no es necesario que empieces de cero con un proyecto tradicional de Django
Lo mismo con Pinax Apps
Pinax CLI
También puedes usar Pinax CLI para instalar un Pinax Starter Project en lugar del proyecto tradicional de Django
Hay un comando especial de Pinax CLI para hacer esto `pinax start
Cuando Pinax CLI ejecuta este comando
El Pinax CLI usa el mismo startproject comando usado para instalar un proyecto tradicional de Django
Pero Django llama lo desde el base de código de Pinax CLI
Pinax CLI
El URL del starter project se pasa como un parámetro
Archivo projects.json
La URL conduce a un archivo (projects punto json) projects.json que proporciona la dirección del archivo tar en el repo de los Pinax Starter Projects
Pinax Starter Projects
Los starter projects están en uno repo
Cada starter project está en una branch individual
Pinax Apps en Starter Projects
Cada starter project contiene las Pinax apps relevantes, para ser instaladas desde PyPI (el Python Package Index)
Algunos detalles importantes sobre manteniendo las Pinax apps
Usamos GitHub Flow flujo de trabajo
Para el versionado semántico
Usamos CalVer en el release-nivel (año punto mes)
Usamos SemVer en el aplicación-nivel (major punto minor punto patch)
Pinax App Código
Cada Pinax app base de código vive en un GitHub repo
Profesional Nivel Configs
Cada aplicación repo tiene configuraciones del nivel profesional usado por mantener el código actualizado
CircleCI es para continuous integration
(setup punto py) setup.py contiene packaging configs
tox es para testing la Python/Django versiones matrix
Actualizar la Test Matrix
Cuando hacemos un release, actualizamos la test matrix para apoyar las últimas versiones de Python y Django
En mi release plan, yo documentó un fragmento de la test matrix para copiar y pegar en los archivos de la aplicación
pyenv y tox
El proceso es que...
Yo clone el Pinax app repo localmente, y creo una branch nueva
Yo actualizo la test matrix en la branch
Hay una herramienta llamada pyenv que puedes usar para instalar múltiples versiones globales de Python localmente
Cuando se ejecuta tox, tox puede usar estas versiones globales para comprobar la compatibilidad del código de la Pinax app con las nuevas versiones de Python y Django
Cuando hay una incompatibilidad, tox le mostrará el error en rojo
Cuando todas las tests pasen… se mostrará en verde al final
Python/Django Release Notes
Mientras se solucionan estas incompatibilidades
Las Python y Django release notes explican todos los cambios realizados en el base de código de Python/Django en el release
Puedes usar las release notes para entender qué actualizaciones debes hacer para cumplir
Actualizar SemVer Versión y Change Log
Cuando todas las test matrix y otras actualizaciones están completos
Querrá actualizar la versión de SemVer en el (setup punto py) setup.py
Y también las versiones en el (setup punto py) setup.py metadatos y README
Actualizar el Change Log en el README
Estas son algunas de las piezas varios de metadatos
Tag y Publish
Entonces, vaya a la "tags" área del repo
Draft una release nueva
Incluye un enlace al Change Log
Ejecutas un proceso localmente para package la aplicación
He documentado este proceso en el repo punto github en el archivo RELEASE.md
Y publish el package en PyPI
20.07 (veinte punto cero siete) Release
En Julio 2020 (dos mil veinte), supervisé la finalización de una Pinax release importante
Incluía aproximadamente 28 (veinte ocho) aplicaciones y notablemente discontinuamos el soporte para Python 2.7 (dos punto siete)
Fue un hito importante para mí, personal y profesionalmente
Inicié el release, gestioné el proceso de principio a fin, creé el plan del release, supervisé el trabajo de otros, actualicé 10 (diez) aplicaciones yo mismo, merged todos los pull requests, y tagged y published los packages
Algunas Lecciones Aprendidas de Pinax
Algunas Lecciones Aprendidas de Pinax
Simplificado, Autoservicio, Autosostenible
He intentado para solucionar algunos de los problemas críticos de Pinax
El objetivo en general ha sido implementar cambios para hacerlo más sencillo y autoservicio
Como resultado, los principiantes, colaboradores y mantenedores podrían ayudarse a sí mismos
Y por lo tanto, crear una cultura que pueda sostenerse a sí misma
Mejoras Importantes que He Dirigido
Mejoras importantes que he dirigido
Documentación del conocimiento tribal
Consolidation de docs, en un lugar fácil de encontrar
Estandarización de las configuraciones entre proyectos
Creación de docs detallados de release y mantenimiento
Creación de Community Health Files, incluidas Issue y Pull Request Templates
Reducción significativa del número de issues y pull requests para estar al día con los nuevos issues y pull requests
La Importancia de Publicidad
Una de las lecciones más importantes que he aprendido de Pinax
A veces es contrario a la intuición
A veces es importante parar y comunicar tus progresos y planes a la comunidad
Y pedir ayuda
Por ejemplo, porque de mis publicaciones de blog, recibí ayuda que fue crucial para completar la última release de Pinax
Agotamiento (Burnout)
Hay un peligro real de agotamiento en código abierto
Es un sujeto triste
Los autores del código y los mantenedores están generoso
A veces trabajan demasiado
Y, por desgracia, a veces ellos tienen que lidiar con las actitudes negativas de los usuarios del código
No estoy seguro Pinax va estar saludable y prospere de nuevo
Pero he aprendido mucho de Pinax
Yo quiero hablar de algunas maneras de hacer una comunidad autosuficiente
Para los mantenedores, colaboradores y usuarios
Reducir el Alcance
Maneras de reducir el alcance
Marcar repos como obsoletos
Archivar repos
Desactivar issues
Comunicar que los mantenedores mantienen el código esporádicamente
Automatización Adicional
Puedes implementar automatización adicional para reducir la carga de trabajo
Estos son algunos lugares donde puedes encontrar herramientas de automatización
