[DOC] - actualizar README, item Como colaborar

[gacsnic]

El procedimiento para colaborar le faltan detalles por cubir
Todo colaboracion de codígo debe hacerce mediante PULL PULL REQUEST desde la rama/branch "develop"
Reporte de errores, bugs, se hacen mediante issue, solicitudes de mejoras tambien.

** Sugerir corrección o mejora o incorporación o eliminación **

Como colaborar (¡IMPORTANTE!).

1. Crear un issue

   crear ticket en issue , si aún no existe, si existe ya un ticket y ya esta asignado no deberá comunicarse con la persona que tiene el issue asignado si quiere aportar mejoras al issue existente.

   Si el issue no esta asignado, cualquiera de los colaborador se lo puede asignar. Ningun colaborador podrá trabajar en un issue si no a especificado o que esta asignándose el issue.

2. Trabajar en con Issue.
   Todo los colaboradores que tengan issue asignada, para trabjar en sus contribución deberán crear una rama partiendo de develop .
   El nombre de la rama estará compuesto de un prefijo+ descripción + ID del issue
   ejemplo.

• bug/structurecode45
• feature/rpttipocuenta46

3. Enviar cambios

   para enviar los cambio debe asegurarse que el código compila, hacer los tes unitarios correspondiente

   crear PR (solicitud de extracción).
   Solicitar revisión por medio de slack a los demas colaboradores.

4. Combinar cambios (realizado por un confirmador)

   Antes de combinar los cambios con la rama develop, los cambios deberá ser revisados y aprobados por dos colaboradores. ya con el visto bueno de dos colaboradores un tercer colaborador procede a hacer la combinación a develop.

5. Limpieza

   El colaborador que tiene el issue asignado deberá esperar al menos 3 dias después de haberse cumplido el paso 4 para eliminar la rama con la que se propuso la modificación.

[jselvamadrigal]

@gacsnic me parece que el nombre de las ramas es muy largo, se podría simplificar

type/id

Ejemplo

task/58
bug/26

La descripción ya se encuentra en el issue, lo veo innecesario.

[jselvamadrigal]

@gacsnic también seria bueno incluyeras en los step para contribuir el uso del Project que se encuentra en el repositorio

[gacsnic]

@gacsnic me parece que el nombre de las ramas es muy largo, se podría simplificar

type/id

Ejemplo

task/58
bug/26

La descripción ya se encuentra en el issue, lo veo innecesario.
El prefijo es idea mía, lo del nombre y el id issue lo tome de Apache tomee, ok mira la siguiente imagen

imagina que necesitamos ver las modificaciones que hizo Armando a la estructura del proyecto y que las ramas están a como las describes, ve una rama feature/55 cambiado de la pestaña code a la pestaña Issue y veo isssue#55 no es lo que busco volvernos a code para ver otra la rama por que la rama feature/55 no era lo que buscabamos y vimos task/48. hacemos el mismo procedimiento....
Pero si contrario a lo anterior vimos una rama con el nombre dev-new-arch-proposal .....
Como veras puede ser mas costoso el no ser descriptivo con el nombre de las ramas. si quieren quitamos lo de los prefijos, pero si los nombre deben ser lo mas descriptivo posible.

[gacsnic]

@gacsnic también seria bueno incluyeras en los step para contribuir el uso del Project que se encuentra en el repositorio

Lo de los proyecto no lo manejo, pero voy investigar para agregarlo. Gracias por los aporte

[jselvamadrigal]

@gacsnic sigo en desacuerdo con el nombre de la rama, en principio el colaborador no debería de buscar la rama, debe de revisar los issue que le interesan y no estar navegando entre ramas, en el caso de armando es una rama especial como develop ya que el no realizo un issue antes de hacer sus cambios. @luchonetvv Que opinas.

[gacsnic]

@gacsnic sigo en desacuerdo con el nombre de la rama, en principio el colaborador no debería de buscar la rama, debe de revisar los issue que le interesan y no estar navegando entre ramas, en el caso de armando es una rama especial como develop ya que el no realizo un issue antes de hacer sus cambios. @luchonetvv Que opinas.

@jselvamadrigal Entiendo bueno talves con esta imagen te puedo convencer

edito para agregar el link de flujo de trabajo para contribuir en Apache tomee http://tomee.apache.org/community/contributing/workflow.html

[luchonetvv]

@gacsnic las ramas deben ser descriptivas en su mayoría de casos te recomiendan empezar con el tipo y el identificador, ademas se puede agregar de 2 a 4 palabras para describir la tarea pero si es muy largo me parece que con el tipo e identificador del issue quedaría corto, al final cualquiera que se escoja debemos ser consistente aca un ejemplo: https://deepsource.io/blog/git-branch-naming-conventions/ en mi trabajo actualmente se utiliza el tipo y código asociado al ticket de Jira aparentemente el tipo/id viene siendo una practica muy común en el versionamiento acá otra referencia https://medium.com/tarkalabs/git-branch-naming-convention-60af30cd9a07

[jselvamadrigal]

Estoy de acuerdo con @luchonetvv para mi las ramas deben de tener nombres simples ojo CUANDO son procedentes de un GIT-FLOW osea tienen un ORIGEN en un ISSUE, para ramas que su origen no es un ISSUE como develop o master me parece bien que sea descriptivo el nombre, pero si lo que necesitas es revisar el trabajo de un ISSUE debes de ir primero a buscar ese ISSUE, saber de que trata, por que se origino, y luego bajar el código en este caso su rama asociada.

[luchonetvv]

otra observación tomando en cuenta al momento de crear un Issue lo tenemos con el siguiente formato como [FEATURE] - Descripción corta y debajo de el el ID, podemos decir que sería fácil de entender que dicho Branch corresponde a dicho Issue, llegando a tener consistencia con lo nombres.

[yesserm]

no se podría combinar con #43 ? tenía pensado tomarlo desde un nivel muy básico, recuerdo aún cuando hice mi primer Pull Request... no sabía que era un fork.

[gacsnic]

no se podría combinar con #43 ? tenía pensado tomarlo desde un nivel muy básico, recuerdo aún cuando hice mi primer Pull Request... no sabía que era un fork.

ups.. estoy invadiendo issue, procede #43 y el #57 debe quedar como soporte del #43, considero que es lo correcto.
@yessermiranda13 , esta propuesta la adapte de la documentación de tomee puede servir para que completes el Issue #43 si lo miras bien claro.

[yesserm]

La verdad me serviría algunos aportes, veo que que en este issue, hay cosas que no me había imaginado incluir, me servirá...