Contribuyendo al desarrollo de Giveth

Giveth actualmente mantiene tres productos que se centran en la gestión de fondos, las donaciones entre pares y la economía de tokens de DeFi para siempre. Estos son Giveth TRACE, Giveth.io y GIVeconomy respectivamente

Todos nuestros productos comparten algunos estándares de desarrollo comunes que es primordial aprender antes de participar en cualquier desarrollo para Giveth. En este documento, le mostraremos cómo interactuar con nuestros repositorios de código abierto, ponerse en contacto con las personas adecuadas y cómo comenzar a crear y seleccionar problemas.

Gestión de Github

Lo primero es lo primero, deberá instalar la extensión zenhub para github para su navegador web que le permitirá ver los espacios de trabajo y las canalizaciones que usamos en Github para gestionar problemas.

Hemos hecho la transición para administrar las tres DApps (productos) en un solo espacio de trabajo, All-Devs.

Repositorios

La organización Giveth Github tiene muchos, muchos repositorios. Aquí hay una descripción general de los repositorios relevantes que se relacionan con nuestros productos activos:

Productos	Repositorios	Descripción
Giveth.io	gráfico de impacto	Backend de Giveth.io
Giveth.io	giveth-next	Giveth.io version actual
Giveth.io	giveth-io-typescript	Givethio typescript version con nuevo diseño
GIVEeconomy	GIVeconomy	Por lo general, se utiliza para la planificación y el seguimiento de problemas.
GIVeconomy	giv-token-contratos	Implementaciones de contratos inteligentes
GIVeconomy	liquidez-minería-dapp	GIVeconomy Frontend UI
GIVeconomy	giv-token-subgraph	Calculating $GIV data para GIVeconomy Frontend
GIVeconomy	givback-calculation	Calculating GIVbacks
TRACE	giveth-dapp	Frontend y planificación de la giveth TRACE
TRACE	feathers-giveth	Backend de la Giveth TRACE
TRACE	dapp-mailer	Sistema de notificación de correo para TRACE
TRACE	giveth-bridge	Giveth Rinkeby - Mainnet Bridge system
Servicios Generales	Sistema de Diseño de IU	npm package for Giveth design assets

Pipelines en el espacio de trabajo All-Devs

Cuando ingresa a un espacio de trabajo en la pestaña Zenhub, verá una línea de columnas adyacentes que se utilizan para identificar y administrar los estados de los problemas que se encuentran actualmente en los repositorios. Puede encontrar una breve descripción de cada uno a continuación:

Nuevos problemas: los nuevos errores y características van aquí primero.

Epics - Pipeline para problemas épicos. Tareas más grandes compuestas de varios problemas más pequeños.

Icebox: funciones o sugerencias que se han archivado. Los problemas aquí no son prioritarios y pueden agregarse a los sprints solo si los desarrolladores tienen el ancho de banda.

Atraso: problemas de menor prioridad que esperan ser incluidos en Sprint Planning.

Sprint Backlog: estos problemas se examinaron y están listos para trabajar en ellos. Se agregarán al próximo sprint según la prioridad y el ancho de banda del desarrollador.

En curso: los desarrolladores lo han recogido y están trabajando en él, normalmente en compilaciones locales.

Revisiones de código: solicitudes de incorporación de cambios abiertas en espera de revisión y eventual fusión en el servidor de ensayo.

info

Es obligatorio que uno de los miembros del equipo central revise el código, generalmente su mentor o el que le presenta el proyecto puede revisarlo, solicite una revisión antes de enviarlo a cualquier entorno.

Pruebas/control de calidad de UAT: la función o corrección de errores se implementa en el servidor de prueba para pruebas de usuario y control de calidad.

Terminado: la función o corrección de errores se completó y está lista para implementarse en el servidor en vivo.

info

Todos los problemas deben cumplir con los criterios del Departamento de Defensa (Definición de Terminado) para ser aprobados como Terminados y estar en esta columna: Criterios de éxito aprobados (si se mencionan en Historia de usuario/Tarea o problema relacionado) Implementado en ensayo UAT Probado por un probador o PM documentado

Cerrado: la función o corrección de errores se ha copiado en vivo. Se recomienda que todos los problemas cerrados se relacionen con un número de versión en el zenhub y se cierren inmediatamente después de que la versión se publique.

Creación de problemas

La creación de problemas de Github es esencial para garantizar que las correcciones de errores o las características se rastreen correctamente y que la información relevante se pueda organizar y consolidar. La nueva plantilla de publicación es solo una guía, siéntete libre de eliminar cualquier título que no uses.

Las etiquetas ayudarán a agregar contexto a su problema, utilícelas para que otros desarrolladores puedan comprender mejor los problemas de un vistazo y recogerlos. Algunas etiquetas de uso común en All-Devs son:

seguimiento rápido: características o mejoras prioritarias luego del lanzamiento de un producto o lanzamiento de una versión.

documentación - Solicitud de creación o actualización de documentación técnica.

bugs - Funcionalidad o característica de un producto que está roto o no funciona según lo previsto

solicitud de función - Solicitar que se agregue una nueva característica o funcionalidad a un producto

diseño necesario - Solicitud de apoyo del equipo de diseño para crear activos relevantes para este problema

pregunta - Hay una pregunta pendiente dentro de este problema que necesita una respuesta para seguir adelante

security - Problema o mejora de seguridad

UI: este problema se relaciona con la interfaz de usuario de un producto determinado

UX: este problema se relaciona con la experiencia del usuario de un producto determinado

Ceremonias

Organizamos en Giveth Discord muchas reuniones de desarrolladores a lo largo de la semana, que incluyen:

• Standups diarios de desarrollo de martes a jueves a las 6:30 am GMT-6
• All-Devs Sync semanalmente los lunes a las 10:00 am GMT-6
• GIVeconomy Sync semanalmente los miércoles a las 8:00 am GMT-6

Estas reuniones son lugares importantes para mantenerse al día con el desarrollo de DApp y para integrarse con el equipo de Giveth como colaborador de desarrollo.

Gestión de Sprint

Marco: Estamos practicando principalmente Scrum, en iteraciones quincenales (llamadas sprints), a veces en base a situaciones de proyectos que pasamos a KanBan.

¿Qué es Scrum?

En scrum, el sprint es un período de tiempo determinado en el que se realiza todo el trabajo. Sin embargo, antes de que pueda pasar a la acción, debe configurar el sprint. Debe decidir cuánto durará el cuadro de tiempo, el objetivo del sprint y dónde comenzará. La sesión de planificación del sprint inicia el sprint estableciendo la agenda y el enfoque.

• El qué: el propietario del producto describe el objetivo (o meta) del sprint y qué elementos del backlog contribuyen a ese objetivo. El equipo de scrum decide qué se puede hacer en el próximo sprint y qué harán durante el sprint para que eso suceda.

• El cómo: el equipo de desarrollo planifica el trabajo necesario para lograr el objetivo del sprint. En última instancia, el plan de sprint resultante es una negociación entre el equipo de desarrollo y el propietario del producto basada en el valor y el esfuerzo.

• The Who: no puedes planificar el sprint sin el propietario del producto o el equipo de desarrollo. El propietario del producto define el objetivo en función del valor que busca. El equipo de desarrollo necesita comprender cómo pueden o no lograr ese objetivo. Si alguno falta en este evento, hace que la planificación del sprint sea casi imposible.

• Las entradas: un excelente punto de partida para el plan de sprint es la acumulación de productos, ya que proporciona una lista de "cosas" que podrían ser parte del sprint actual. El equipo también debe observar el trabajo existente realizado en el incremento y tener en cuenta la capacidad.

• Los resultados: el resultado más importante de la reunión de planificación del sprint es que el equipo pueda describir el objetivo del sprint y cómo comenzará a trabajar hacia ese objetivo. Esto se hace visible en el Sprint Backlog.

Antes de que comience la iteración, es posible que deba tener las horas de contribución totales esperadas en Hoja de cálculo de planificación de recursos de Giveth, el enlace generalmente está compartido en el canal de desarrolladores de Discord antes de la reunión de sprint. Puede encontrar la hoja de sprint y actualizar las siguientes celdas:

Ayuda a los Directores de Producto (PM) a planificar mejor los recursos y saber si pueden alcanzar el hito en cada sprint o no. Si no pudo encontrar tiempo para completar la hoja de cálculo, es posible que se le pida que lo haga durante la reunión o cada vez que pueda tener un presupuesto, simplemente envíelo por mensaje privado a los mensajes privados o colóquelo en el canal de desarrollo.

La planificación de sprint habitual es así:

1. Los PM traen los problemas (preferiblemente Historias de usuarios) a la reunión de planificación, descríben el problema y asegúrese de que esté claro para que el equipo comience a implementarlo.
2. PM facilita las conversaciones entre desarrolladores para dejarlo lo más claro posible.
3. PM solicita estimaciones en Story Points (Story Points son la unidad de esfuerzo mínimo gastado en un producto que se puede entregar lo antes posible, como una simple corrección de errores, por ejemplo, podría tomar la mitad de un día laboral).
4. PM comienza a construir "Sprint Backlog" priorizando los problemas y se asegura de que la cantidad total de Story Points sea proporcional a la capacidad total de los equipos y colaboradores.
5. Todos están de acuerdo con el plan de sprint y se comprometen con la meta esperada.

Contactos Importantes

• Administrador del grupo de desarrolladores - Amin
  • Discord de Contacto: Amin#2164
• Director de producción de GIVeconomy - Lauren
  • Discord de Contacto: karmaticacid#1218
• Director de Producción de Giveth TRACE, Giveth.io - MoeNick
  • Discord de Contacto: MoeNick#1374
• Desarrollador Principal Giveth.io - Mateo
  • Discord de Contacto: mateodaza#3156
• DevOps & Security - Kay
  • Discord de Contacto: geleeroyale#3228
• Diseñador Principal - Marko
  • Discord de Contacto: markop#2007

Guías de Instalación para el Desarrollo Local

• Giveth.io
• Giveth TRACE
• GIVeconomy

Directrices de prueba

• Giveth.io
• GIVeconomy

Herramientas que usamos

• Segment (Giveth TRACE, Giveth.io)
• Sentry (Giveth TRACE, Giveth.io)
• Infura (Giveth TRACE, Giveth.io)
• Autopilot (Giveth.io)
• Amplitude (Giveth TRACE, Giveth.io)
• Docusaurus (Documentation)
• The Graph (GIVeconomy)
• Netlify (Giveth TRACE)
• Vercel (Giveth.io, GIVeconomy)
• Cryptocompare (Giveth TRACE)
• Coingecko (All Products)
• Github Actions (All Products)
• MongoDB (Giveth TRACE)
• PostgreSQL (Giveth.io)
• Redis (Giveth TRACE, Giveth.io)
• Elastic Search (Giveth TRACE)
• Kibana (Giveth TRACE)
• Pinata (Giveth.io, GIVeconomy)
• Transak (Giveth.io)
• AdminBro (Giveth.io)