Para nosotros tú contribución es muy importante, y en pro de mantener un orden en nuestros repositorios hemos creado este archivo contributing.md
, para que puedas enviar todos tus aportes.
Aquí están los lineamientos para poder contribuir.
En los proyectos de "Full Dev Web", tenemos 3 branches, o ramas por defecto:
master
.develop
.gh_pages
.
Te recomendamos nombrar los branches o ramas de tus colaboraciones para "Full Dev Web" con el prefijo: js
seguido por la convención de tú preferencia. A nosotros nos agrada esta:
<prefijo js>-<palabra "issue">-<numero de issue>-
.
Quedaría algo como esto: js-issue-14-encuesta
. Pero también es válido algo como esto: js-issue-20
.
El branch master
es tratado como "producción", gh_page
sera la rama de despliegue usando GitHub Pages y develop
como el de "ci", o "qa", por lo consiguiente, se deben crear branches o ramas individuales, a partír de develop
para cualquier aporte, luego en el pull request
se debe especificar que el nuevo cambio será unirá a develop
.
¡NUNCA! debemos hacer merge a master
ya que estaríamos haciendo cambios a "PRODUCCION".
Tenemos una estructura a seguir, para facilitar la validación de tus contribuciones y mantener un buen flujo de trabajo. Los mensajes de commits deberían ser de la siguiente manera:
<Tipo>(<Ámbito>): <Mensaje Corto>
<LINEA EN BLANCO>
<Mensaje Explicativo>
El Encabezado: tipo(ámbito): <Mensaje Corto>
es obligatorio, el resto es opcional. Las acciones disponibles, puedes encontarlas en Acciones, un poco más abajo.
Cualquier línea en un mensaje de commit no de ser mayor de 100 caracteres!. Esto permite la fácil lectura de los mensajes tanto en Github como en varias herramientas de git.
Commit Corto:
(Agrega): Clase Utils para lectura de atributos.
Commit Largo:
(Agrega): Clase Utils para lectura de atributos.
La clase utils,esta divida en varios métodos para diferentes usos.
Para validar se usan los siguientes métodos.
ValidaPhone.
ValidaIp
ValidaNavegador
ValidaNovias
Por favor asegurate que tú pull request
cumpla los siguientes lineamientos:
- Crea un
pull request
individual por cada aporte. - Sigue las indicaciones dadas en la plantilla de
pulls requests
. - Usa
title-casing
(AP style). - Presta mucha atención a tu ortografía.
- Nuevos aportes o mejoras a lo que ya existe, siempre es bienvenido.
Las acciones son los indicativos primordiales de los cambios que realizamos en un determinado archivo. Con éstas lo que intentamos es saber con una simple lectura que tipo de modificació fué hecha. Actualmente tenemos estás acciones disponibles:
- Agrega: Usalo para notificar una nueva funcionalidad, o algún comportamiento que antes no estaba.
- Elimina: Cuando eliminas alguna funcionalidad, tratamiento o porción de codigo, sin afectar un comportamiento.
- Modifica: Al cambiar sustancialmente un comportamiento, funcionalidad o tratamiento.
- Actualiza: Exclusivamente para documentos informativos, o dependencias utilizadas.
- Correccion: Si existe un bug, y es solventado, esta acción es la ideal para avisarlo.
- Refactor: Cuando se hace un cambio de logica, comportamiento o funcionalidad de manera sustancial.
El ámbito es el lugar de la aplicación donde se realiza el cambio.
El mensaje debe contener una descripción clara y concisa del cambio realizado.
- Use tiempo presente imperativo, agrega, no agregado ni agregó.
- No capitalizar la primera letra.
- No coloque punto (.) al final
Si quieres proponer un nuevo tipo de "Accion", puedes abrir un issue
, para ello en este enlace
¡Importante!: Las contribuciones que no cumpla con las recomendaciones acá expuestas no será aceptadas.
Agradecimientos: Comunidad ngVenezuela por permitirnos usar su CONTRIBUTING.md como base para el nuestro. ¡Mil gracias! 😎