Hey! Veo que quieres unirte al desarrollo de esto, pues vale, manos a la obra
Tabla de contenido
- Peticiones de ideas
- Reporte de bugs
- Flujo de colaboracion
- Caja de descripcion
- Documentacion
- Testers
- Pasos de lanzamiento
Todas las solitudes de nuevas de funciones deben de ser enviadas a el reatreador de problemas de ApmPKG. Esto para reducir la cantidad de duplicados.
Todos los parches deben enviarse a github como pull requests si usted deseea empezar a contribuir en ApmPKG puede empezar a atender Buscando ayuda, Solicitud de funciones o en la pagina de proyectos
Primero y antes que nada debe de checar los iusses para empezar a trabajar. Si lo que usted desea es empezar a colaborar desde ahora como lo dice aqui arriba puede empezar a atender el rastreador de problemas tomando como prioridad a los que contiene la etqueta de bug. Pero esto haciendo un nuevo fork a partir del ultimo commit de la rama develop y NO desde master. De manera no obligatorio pero se recomienda modificar la caja de descripcion colocando los datos correspondientes. Una ves que hayas terminado puedes hacer el pull requests pero a la rama develop en donde un tester debe de aceptar dicha mejora, si tu contribuyes a algo beneficioso es muy probable que sea aceptada para mejor organizacion consulte la pagina de proyectos
La caja de descripcion es aquella que se ubica en la parte superior de cada archivo de codigo y debe de ser modificada cada que hace un cambio para el mejor manejo de esta no aplica en los archivos de documentacion, para ello consulte documentacion, dicha caja esta comentada para que interfiera con el codigo. Una caja de descripcion luce algo asi tomando como ejemplo del archivo antes:
#!/bin/bash
##################################################
## ##
## Comprobando conexion a github (ping) v1.0.0 ##
## ##
## Autores: ##
## kedap (דנטה) <[email protected]> ##
## ##
##################################################
echo "Checando conexion con github"
ping github.com -c3
echo "Finalizando el chequeo de conexion"
Despues:
#!/bin/bash
##################################################
## ##
## Comprobando conexion a github (ping) v1.0.0 ##
## ##
## Autores: ##
## kedap (דנטה) <[email protected]> ##
## foo (bar) <example@example> ##
## ##
## [iusse #1] ##
## ##
##################################################
echo "Checando conexion con github"
ping github.com -c3
# Solucion por foo
if [ $? = 0 ];then
echo "Tienes conexion"
else
echo "No tienes conexion"
fi
# Termina la solucion de foo
echo "Finalizando el chequeo de conexion"
Ahora analizaremos la caja de descripcion no es algo dificil, En la primera linea tenemos al mitico
!/bin/bash
Esto forma parte del codigo asi que lo dejamos tal cual, en la siguiente linea nos encontramos a:
Comprobando conexion a github (ping) v1.0.0
Esto es un resumen del archivo y su version, nos enfocaremos mas en la version ya que cuando comparamos el antes y el despues nos damos cuenta que la version tampoco coinside ya que cada vez que haces una nueva mejora en el codigo este va a aumentar un 1 al ultimo, recuerda siempre aumentar ese 1 cada vez que trabajes en una nueva mejora en el codigo. En las siguientes lineas tenemos:
Autores:
kedap (דנטה) <[email protected]>
foo (bar) <example@example>
Pues como es logico en esta parte se coloca el nombre de usuario de github y si deseas en parentesis un alias, desde luego dentro de < > debes de colocar una direccion de correo electronico, esto con la finalidad de que tengamos la necesidad de contactarte referente al codigo. En la siguiente linea encontraremos:
[iusse #1]
Esta linea como todo creemos que es, es el iusse que esta atendiendo. Si navegamos mas en el codigo nos encontraremos con lo siguiente:
Solucion por foo
y
Termina la solucion
Esto se hace para que a nuestros testers sea mas practico encontrar la implementacion que agregaste
El codigo debe de documentarse cuando sea apropiado. Si usted cree que realizo un cambio que necesita ser documentando o simplemente quiere extender la documentacion puede agregar dicha documentacion en el directorio docs e indexarla desde el README. Claro en el fork que usted creo y despues hacer el pull requests a la rama develop en donde aceptaremos tu documentacion
Son una parte fudamental en el crecimiento de este proyecto, son aquellos que se encargan de checar todos los pulls requests, probarlos y aceptarlos, si tu quieres ser parte los testers puede mandar un mensaje a telegram o email
El ciclo de lanzamiento es el siguiente
- Iniciamos con la version 0.1-beta desde la rama master
- Se crea una rama de desarrollo llamada develop
- Se solucionan algunos issues implementacion de mejoras tomando las seleccinadas para la siguiente version (consulte la la pagina de proyectos para mas informacion)
- Es posible que algunos iusses no se les tome importancia, revisaste y no se soluciona dicho iusse que quieres asi que tu decides colaborar
- Creas un fork a partir del ultimo commit de la rama de develop y empiezas a trabajar
- Terminas de trabajar en aquel issues y haces el pull requests a la rama develop y es aceptada. La rama que creaste es elminada pero implementada a la develop
- Ahora se terminan los detalles en la rama develop para hacer pull request a la rama master
- Se hace pull request a master y se afinan mas detalles
- Se lanza la siguiente version!