From 430864fc4b076bbc70270ae8488a1deee77d1bcf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Victor=20Pe=C3=B1a?= Date: Thu, 7 Apr 2022 13:19:50 -0400 Subject: [PATCH] Expanding doc for freelancers --- README.es.md => Creating Issues/README.es.md | 14 ++- README.md => Creating Issues/README.md | 0 Creating Issues/WorkWithUs.es.md | 52 +++++++++++ LICENSE | 2 +- Resolving Issues/EstimationEffortTable.es.md | 37 ++++++++ Resolving Issues/README.es.md | 50 +++++++++++ Resolving Issues/WorkWithUs.es.md | 95 ++++++++++++++++++++ 7 files changed, 247 insertions(+), 3 deletions(-) rename README.es.md => Creating Issues/README.es.md (90%) rename README.md => Creating Issues/README.md (100%) create mode 100644 Creating Issues/WorkWithUs.es.md create mode 100644 Resolving Issues/EstimationEffortTable.es.md create mode 100644 Resolving Issues/README.es.md create mode 100644 Resolving Issues/WorkWithUs.es.md diff --git a/README.es.md b/Creating Issues/README.es.md similarity index 90% rename from README.es.md rename to Creating Issues/README.es.md index e0111ec..985d110 100644 --- a/README.es.md +++ b/Creating Issues/README.es.md @@ -1,6 +1,6 @@ -# Issues +# Guía para crear buenos issues -- [Issues](#issues) +- [Guía para crear buenos issues](#guía-para-crear-buenos-issues) - [¿Qué es un issue?](#qué-es-un-issue) - [Qué debe contener un issue?](#qué-debe-contener-un-issue) - [Descripción:](#descripción) @@ -11,6 +11,8 @@ - [Un issue a la vez](#un-issue-a-la-vez) - [Títulos son importantes](#títulos-son-importantes) - [Si aplica, no olvides añadir:](#si-aplica-no-olvides-añadir) + - [Quiero trabajar con Azordev creando issues](#quiero-trabajar-con-azordev-creando-issues) + - [Quiero trabajar con Azordev resolviendo issues](#quiero-trabajar-con-azordev-resolviendo-issues) - [Bibliografía:](#bibliografía) [Azordev](https://github.com/Azordev/) gestiona casi todo su trabajo a través de GitHub. Por eso es importante que sean issues detalladas y bien creadas. A continuación se muestran algunas de las mejores prácticas para escribir issues de GitHub de forma apropiada. @@ -86,6 +88,14 @@ Por ejemplo, en vez de escribir el título “El campo de búsqueda causa error 2. **Tipo de tareas:** Como se mencionó en [¿Qué es un issue?](#qué-es-un-issue), pueden existir distintos tipos de tareas. Tareas para diseñadores, por ejemplo, pueden llevar la label `design`, mientras que tareas para desarrolladores pueden dividirse por tecnologías, por ejemplo `javascript`, `css`, o pueden dividirse por tipo de tarea, por ejemplo: `api`, `logic`, `style`. 3. **Prioridad:** Este label estipula qué tan pronto se requiere que se solucione algún issue, pueden ser tres o más: `low`, `mid`, `high` +## Quiero trabajar con Azordev creando issues + +Si quieres saber como trabajar con Azordev creando issues, puedes revisar esta sección para saber cómo: [Trabaja con nosotros](WorkWithUs.es.md). + +## Quiero trabajar con Azordev resolviendo issues + +Si eres un desarrollador y quieres saber como trabajar con Azordev resolviendo, puedes revisar esta sección para saber cómo: [Trabaja con nosotros](../Resolving%20Issues/README.es.md). + # Bibliografía: - [Writing a proper issue](https://medium.com/nyc-planning-digital/writing-a-proper-github-issue-97427d62a20f) diff --git a/README.md b/Creating Issues/README.md similarity index 100% rename from README.md rename to Creating Issues/README.md diff --git a/Creating Issues/WorkWithUs.es.md b/Creating Issues/WorkWithUs.es.md new file mode 100644 index 0000000..b14ef15 --- /dev/null +++ b/Creating Issues/WorkWithUs.es.md @@ -0,0 +1,52 @@ +- [Cómo trabajar con Azordev creando tareas](#cómo-trabajar-con-azordev-creando-tareas) + - [Trabajar por proyectos](#trabajar-por-proyectos) + - [Precios por proyectos](#precios-por-proyectos) + - [Trabajar por tareas](#trabajar-por-tareas) + - [Precios por cada tarea](#precios-por-cada-tarea) + - [FAQ](#faq) + - [¿Por qué Azordev paga por crear tareas?](#por-qué-azordev-paga-por-crear-tareas) + +# Cómo trabajar con Azordev creando tareas + +Actualmente puedes trabajar con Azordev de dos maneras, dependiendo de tu disponibilidad de tiempo y tus necesidades: Por proyectos o por tareas creadas. + +## Trabajar por proyectos + +En Azordev siempre estamos innovando, por lo que siempre tenemos nuevas ideas para desarrollar. Así que algo común es que tengamos proyectos en mentes pero no el tiempo de sacarlos adelante, tu responsabilidad si decides trabajar Por proyectos para nosotros, sería escucharnos a nosotros como clientes, para ayudarnos a sacar estos proyectos de la mejor manera, nosotros te brindaremos el equipo técnico y toda la logística necesaria para avanzar, y tú coordinarás los diferentes análisis, sprints y las tareas de cada uno para sacar el proyecto adelante. + +### Precios por proyectos + +Este servicio no tiene precio fijo, el Project Manager que quiera tomar un proyecto deberá hacer su correspondiente cotización del mismo. Entre sus ventajas está que esta práctica es más productiva para un Project Manager, ya que cuenta como experiencia real y puede incluirla en su portafolio. + +## Trabajar por tareas + +Si no tienes el tiempo para llevar un proyecto completo, puedes ayudarnos a crear tareas pequeñas en proyectos ya existentes durante tu tiempo libre. Puedes preguntarnos por los proyectos en que puedes colaborar, y el flujo sería el siguiente: + +1. Entras en el proyecto, revisas el diseño y lo que está actualmente desarrollado. +2. Intentas buscar algún bug en lo que actualmente está, o buscar algo que esté en el diseño, pero no se haya desarrollado ni tenga alguna tarea abierta. +3. Creas la tarea siguiendo la siguiente [guía de estilo](README.es.md) y compartes el link con los encargados de Azordev. +4. El equipo de Azordev validará que el issue sea entendible desde el punto de vista de un desarrollador, y en caso de ser necesario, de un diseñador, se te dejarán comentarios de como mejorarlo, una vez corrijas los comentarios, si no salen más cosas, la tarea será marcada como Aprobada. +5. Una vez la tarea esté aprobada será sumada en tu cuenta para hacerte el pago a final del mes. Revisa la sección de pagos para más información al respecto. + + +### Precios por cada tarea + +Trabajar creando tareas sí tiene una tarifa fija, dependiendo del tipo de tareas que encuentres, existen 4 tipos generales que explicaré a continuación: + +- Issues de tareas: Son issues sobre funcionalidades que ya estaban propuestas y que son necesarios para terminar la aplicación. (5.00 USD). + +- Issues de petición de funcionalidad: Son tareas sobre funcionalidades deseables, que no estaban previstas y pueden ser incluidas a futuro como una nueva funcionalidad. Esto incluye mejoras en el UX/UI o nuevas funcionalidades para la aplicación, siempre y cuando la intención vaya de acuerdo con el alcance y objetivos de la aplicación. (5.00 USD). + +- Issues sobre solucionar errores de la interfaz gráfica: Errores del UX/UI que pueden causar problemas a los usuarios que usan la aplicación, incluyendo seguridad, accesibilidad y ergonomía. (10.00 USD). + +- Issues sobre solucionar errores: Descripción de errores que detienen o rompen la aplicación, impidiendo a un usuario seguir el flujo normal. (10.00 USD). + +## FAQ + +### ¿Por qué Azordev paga por crear tareas? + +La misión en Azordev es ayudar a crecer a los nuevos desarrolladores y obtener experiencia en trabajos reales para que puedan entrar al mundo laboral, para esto usamos una metodología de trabajo por tareas; en lugar de hacer entrevistas y contratar solo a algunos desarrolladores, intentamos abrir diferentes tareas en proyectos de Azordev, de forma que cualquier desarrollador pueda participar realizando tareas acordes a sus conocimientos. + +En un futuro pensamos tener más de 10 desarrolladores trabajando de forma simultanea en diferentes repositorios, por lo tanto para completar el flujo necesitaríamos que hayan personas encargadas de crear tareas de forma que los desarrolladores siempre tengan tareas disponibles para desarrollar. + +Así que pensamos que sería una oportunidad perfecta para Quality Assurances, Testers y Project Managers de unirse a Azordev y ganar dinero en su tiempo libre. Incluso si no eres QA o Project Manager, pero quieres participar ayudándonos a mejorar nuestros productos, solo tienes que seguir esta [guía](README.es.md) sobre como crear tareas y ya puedes empezar a trabajar con Azordev creando tareas. \ No newline at end of file diff --git a/LICENSE b/LICENSE index 26faf25..daee8b5 100644 --- a/LICENSE +++ b/LICENSE @@ -1,6 +1,6 @@ MIT License -Copyright (c) 2022 Víctor Peña +Copyright (c) 2022 Azordev Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/Resolving Issues/EstimationEffortTable.es.md b/Resolving Issues/EstimationEffortTable.es.md new file mode 100644 index 0000000..615fba8 --- /dev/null +++ b/Resolving Issues/EstimationEffortTable.es.md @@ -0,0 +1,37 @@ +# Las estimaciones de esfuerzo manejadas por Azordev y sus precios + +- [Las estimaciones de esfuerzo manejadas por Azordev y sus precios](#las-estimaciones-de-esfuerzo-manejadas-por-azordev-y-sus-precios) + - [Tareas de esfuerzo mínimo (EE 1)](#tareas-de-esfuerzo-mínimo-ee-1) + - [Tareas de esfuerzo normal (EE 2)](#tareas-de-esfuerzo-normal-ee-2) + - [Tareas de esfuerzo medio (EE 3)](#tareas-de-esfuerzo-medio-ee-3) + - [Tareas de esfuerzo alto (EE 4)](#tareas-de-esfuerzo-alto-ee-4) + - [Tareas de esfuerzo muy alto (EE 5)](#tareas-de-esfuerzo-muy-alto-ee-5) + +Las estimaciones de esfuerzo son una manera de manegar el valor de una tarea, dado que no todas las tareas son iguales y no todas requieren el mismo esfuerzo o tiempo, sería injusto que todas las tareas tuvieran el mismo valor. + +La estimación de esfuerzo define el tiempo que podría tomar una tarea, el precio de esta e incluso toca un poco el tema acerca del tipo de tarea, siendo algunas más difíciles o complejas que otras. A continuación, procedo a explicar cada una: + +## Tareas de esfuerzo mínimo (EE 1) +Son tareas sencillas y de corta duración. Principalmente arreglos de bugs o reparación de errores que no requieran tanto tiempo. +> Tiempo estimado: < 60 minutos. +> Precio por la tarea: 5 USD. + +## Tareas de esfuerzo normal (EE 2) +Son tareas que no dejan de ser sencillas, pero requieren algo más de tiempo, como cambiar algunos aspectos visuales de la aplicación o mejoras en el código por ejemplo. +> Tiempo estimado: 1 hora - 3 horas. +> Precio por la tarea: 10 USD. + +## Tareas de esfuerzo medio (EE 3) +Estas tareas requieren algo más de esfuerzo y tiempo pero no llegan a ser tan complicadas. Serían en su mayoría crear o migrar páginas o vistas no tan complejas, solución de errores más avanzados, entre otros. +> Tiempo estimado: 3 horas - 5 horas. +> Precio por la tarea: 15 USD. + +## Tareas de esfuerzo alto (EE 4) +Estas son tareas complejas y algo largas, principalmente serían tareas en las que se resolverán muchos errores complicados, ajustes avanzados en la parte visual, crear páginas complejas, entre otras acciones. +> Tiempo estimado: 5 horas - 8 horas. +> Precio por la tarea: 20 USD. + +## Tareas de esfuerzo muy alto (EE 5) +Las tareas con esta etiqueta son extremadamente largas o complejas, ya que requieren de mucho tiempo para terminarlas, serán raras, pues, lo ideal sería dividir el trabajo en tareas más cortas o de esfuerzo medio, pero se usaría en el caso que se necesite. +> Tiempo estimado: > 8 horas +> Precio por la tarea: Negociable según el tiempo que le tome al desarrollador \ No newline at end of file diff --git a/Resolving Issues/README.es.md b/Resolving Issues/README.es.md new file mode 100644 index 0000000..a030904 --- /dev/null +++ b/Resolving Issues/README.es.md @@ -0,0 +1,50 @@ +# Trabajar para Azordev resolviendo issues + +- [Trabajar para Azordev resolviendo issues](#trabajar-para-azordev-resolviendo-issues) + - [Ventajas](#ventajas) + - [No hay horarios](#no-hay-horarios) + - [No hay presión](#no-hay-presión) + - [Aprende haciendo](#aprende-haciendo) + - [No necesitas conocer todo](#no-necesitas-conocer-todo) + - [Trabaja en equipo](#trabaja-en-equipo) + - [Se te paga por tu esfuerzo](#se-te-paga-por-tu-esfuerzo) + - [Obtén una certificación por tu trabajo](#obtén-una-certificación-por-tu-trabajo) + - [¿Cómo puedo empezar?](#cómo-puedo-empezar) + +En Azordev buscamos innovar en el mercado tecnológico implementando nuevas metodologías de trabajos que dan oportunidad a developers freelancers de todo el mundo a adquirir experiencia y remuneración monetaria ayudando a solucionar tareas de proyectos reales. + +Si eres un desarrollador, ya sea que estés comenzando o que ya tengas experiencia, puede que te interese trabajar por tareas con Azordev, te mencionaré algunas de las ventajas: + +## Ventajas + +### No hay horarios + +Puedes entrar, tomar una tarea y desarrollarla en tu tiempo libre, serás recompensado por hacer esa tarea. + +### No hay presión + +Un gran problema al tomar un proyecto, es que si no terminamos el proyecto completo en una cantidad limitada de tiempo, quedamos mal con el cliente. En Azordev esta presión se reduce, dado que en lugar de contratarte para que realices un proyecto grandísimo que seguramente llevará meses, solo eres responsable de terminar las tareas que tú mismo te asignaste, luego de eso, si no tienes tiempo eres totalmente libre de ausentarte hasta que tengas tiempo y quieras volver a tomar tareas en Azordev. + +### Aprende haciendo + +Si estás comenzando lo más probable es que tengas dudas respecto a alguna tarea, o te bloquees o no sepas como avanzar. Si es el caso, tenemos desarrolladores dispuestos a ayudarte. Por otro lado, puedes aprender mucho sobre buenas prácticas gracias a Code Review que se realiza en equipo. + +### No necesitas conocer todo + +Algo muy común, y de hecho muy buena práctica en la programación, es dividir todo por responsabilidades, el backend separado del frontend, los estilos separados de la lógica, cada función comete una sola acción... Esta misma práctica, hemos tratado de emplearla en la metodología de trabajo de Azordev, haciendo que hayan trabajos disponibles para cualquier developer sin importar si solo conoce un lenguaje. Te dejo este ejemplo: Aprendiste CSS, pero no te gusta JavaScript, lo más probable es que te cueste empezar a trabajar en otros lugares porque te piden como requerimiento saber JavaScript, CSS, HTML, NodeJS, y mil requerimientos más. En Azordev conseguirás tareas donde no necesitas saber nada más que CSS, y se te recompensará por tu tiempo y conocimientos. + +### Trabaja en equipo + +Emplea y reforza tus conocimientos de Git, GitHub, y obtén experiencia real de como es trabajar con un equipo usando Git y GitHub, recibe revisión de tu código y comenta en el código de otros, participa en comentarios de issues, discusiones, pull requests. + +### Se te paga por tu esfuerzo + +Tratamos de que el sistema de pago sea justo, dándole una estimación de esfuerzo a cada issue, para que te sea recompensado por la cantidad de esfuerzo que requiere una tarea para ser terminada. Si quieres leer sobre las estimaciones de esfuerzo, qué significan y los precios actuales para cada una, [haz click aquí](WorkWithUs.es.md). + +### Obtén una certificación por tu trabajo + +Somos una empresa registrada legalmente en Colombia, por lo que podemos darte una carta de trabajo que indique que trabajaste para nosotros, por cuanto tiempo y lo que hiciste en ese tiempo, lo cual es perfecto para mostrar en tu portafolio y así mostrar tu experiencia a otras empresas. + +## ¿Cómo puedo empezar? + +Si estás interesado en comenzar a ganar experiencia trabajando con Azordev y ser recompensado por tus conocimientos de programación, puedes leer esta documentación sobre [cómo comenzar](WorkWithUs.es.md) \ No newline at end of file diff --git a/Resolving Issues/WorkWithUs.es.md b/Resolving Issues/WorkWithUs.es.md new file mode 100644 index 0000000..f20129d --- /dev/null +++ b/Resolving Issues/WorkWithUs.es.md @@ -0,0 +1,95 @@ +# Cómo trabajar con Azordev creando tareas + +- [Cómo trabajar con Azordev creando tareas](#cómo-trabajar-con-azordev-creando-tareas) + - [Como encontrar las tareas](#como-encontrar-las-tareas) + - [Como solicitar que me asignen a una tarea](#como-solicitar-que-me-asignen-a-una-tarea) + - [Como empezar a solucionar la tarea a la que fui asignado](#como-empezar-a-solucionar-la-tarea-a-la-que-fui-asignado) + - [¿Qué debo hacer si aún no tengo permisos en el repositorio?](#qué-debo-hacer-si-aún-no-tengo-permisos-en-el-repositorio) + - [¿Qué debo hacer si ya tengo permisos en el repositorio?](#qué-debo-hacer-si-ya-tengo-permisos-en-el-repositorio) + - [¿Qué debo hacer luego de crear el Pull Request?](#qué-debo-hacer-luego-de-crear-el-pull-request) + - [¿Cuándo me pagan?](#cuándo-me-pagan) + - [Condiciones](#condiciones) + - [Negociación](#negociación) + - [FAQ](#faq) + - [¿Qué es el Code Review?](#qué-es-el-code-review) + +Si te interesa empezar a trabajar como freelancer para Azordev resolviendo tareas, puedes seguir esta guía sobre el flujo de trabajo que existe en Azordev: + +## Como encontrar las tareas + +1. Ve a GitHub y entra en la [organización de Azordev](https://github.com/Azordev/). +2. Allí verás unos repositorios fijados, esos son los repositorios que se están trabajando actualmente. Siéntete libre de navegar por ellos, revisarlos, estudiarlos y busca el que más te llame la atención o más se adapte a tus conocimientos. +3. Una vez hayas escogido algún repositorio, puedes dirigirte a la sección de `issues` para ver las tareas que estén disponibles. + +## Como solicitar que me asignen a una tarea + +1. Notarás que hay algunas tareas que no tienen a nadie asignado, esas tareas están libres de ser tomadas, siempre y cuando no tengan ninguna label `Blocked` or `Need design`. +2. Una vez hayas encontrado alguna issue que te llame la atención, entra en el issue y comenta que te gustaría ser asignado, por ejemplo: "Me gustaría ayudar a resolver esta issue", un encargado te leerá y te asignará la issue. + +## Como empezar a solucionar la tarea a la que fui asignado + +Una vez hayas realizado el paso anterior sobre [como solicitar que te asignen a una tarea](#como-solicitar-que-me-asignen-a-alguna-tarea), puedes empezar a solucionarla. + +Esto depende de si [ya tienes permisos en el repositorio](#ya-tienes-permiso-en-el-repositorio), o [si aún no se te han dado permisos](#aún-no-tienes-permisos-en-el-repositorio). Explicaré los dos casos a continuación + +### ¿Qué debo hacer si aún no tengo permisos en el repositorio? + +Si aún no tienes permisos en el repositorio, puedes solicitar permisos escribiéndonos a [contacto@azordev.com](mail:contacto@azordev.com) o comentando en el issue que te den permisos. + +Si por alguna razón no te hemos dado permiso todavía, y quieres comenzar a trabajar sin esperar, puedes crear un Fork de nuestro repositorio y trabajar desde allí. Puedes seguir esta documentación de GitHub acerca de [como crear un fork](https://docs.github.com/es/get-started/quickstart/fork-a-repo), allí explican qué son, cómo se crean, para qué sirven y cómo puedes colaborar usandolas. + +Una vez tengas permisos o hayas creado un fork, puedes continuar con la [siguiente sección](#qué-debo-hacer-si-ya-tengo-permisos-en-el-repositorio) + +### ¿Qué debo hacer si ya tengo permisos en el repositorio? + +Si ya tienes permisos en el repositorio o has creado un fork, puedes seguir los siguientes pasos: + +1. Una vez ya estés asignado, puedes ir al README.md de ese repositorio para ver cómo puedes clonarlo y correrlo. +2. Cuando ya tengas el repositorio clonado en tu PC, lo primero que debes hacer es crear una rama para ese issue, nosotros usamos la siguiente nomenclatura para el nombre de las ramas: `fix|feat/#{issuenumber}`, si el issue trata sobre añadir una nueva funcionalidad se utiliza "feat" al inicio, pero si trata sobre arreglar algún bug, se utiliza "fix". El resultado sería por ejemplo: `fix/#5` o `feat/#1`. +3. Ya con la rama creada, puedes empezar a trabajar en tu issue, una vez tengas los cambios listos, haces el push hacia esa rama: `git add .` -> `git commit -m "{descripción corta de tus cambios}"` -> `git push origin {nombre de tu rama}`. El resultado sería algo así, por ejemplo: `git commit -m "added background color in home view"` -> `git push origin fix/#5`. +4. Una vez hayas realizado el push, github te invitará a hacer un Pull Request, haces el pull request apuntando hacia la rama principal de nuestro repositorio, le agregas un título y descripción agradable que nos ayude a entender el cambio que has realizado y esperas por el Code Review. + +## ¿Qué debo hacer luego de crear el Pull Request? + +Una vez hayas terminado tus cambios y hayas creado el Pull Request, los encargados de Azordev entrarán a revisar tus cambios, a este proceso se le conoce como [Code Review](#code-review). + +Durante esa revisión se te pueden dejar comentarios de cambios necesarios, así como sugerencias. Las sugerencias no son obligatorias pero generalmente son acerca de lo que se considera buena práctica o no, si se aplica o no, no es mucha la diferencia, pero si te interesa aprender de buenas prácticas y mejorar tu código puedes aprovechar esos comentarios para aprender lo que no te enseñan en los cursos. + +Por otro lado, los comentarios acerca de cambios necesarios serán acerca de cosas que no funcionen o que no se vean nada bien en el código y necesiten una mejora. Estos cambios serán necesario aplicarlos ya que afectan el trabajo de los demás developers del equipo, y son cambios que no pueden llevarse con errores a la rama principal. + +Por lo normal, luego de hacer el pull request, el flujo es el siguiente: + +1. Varios encargados de Azordev revisan tu código, pueden aprobarlo, comentar o requerir cambios. +2. Si hay comentarios, lo correcto sería contestarlo, la mayoría de las veces los comentarios serán dudas acerca de tus cambios. Si hay cambios requeridos, lo correcto sería: + 1. ¿Estás de acuerdo con el cambio?: Realiza un nuevo commit con el cambio y haz el push para que se suba a la rama. + 2. ¿Crees que no es necesario o no tiene que ver con la tarea que resuelves?: Háblalo con el equipo para que movamos el comentario hacia una nueva tarea. + 3. ¿Crees que realmente hay una mejor manera de hacerlo?: Háblalo con el equipo para ver la mejor manera de hacer las cosas y así aprendemos y mejoramos todos. +3. Una vez los comentarios hayan sido completados, si no salen más comentarios, entonces el pull request se fusionará con la rama principal, se cerrará el issue al que fuiste asignado, y se te anotarán los puntos de esfuerzo de ese issue para el pago. + +## ¿Cuándo me pagan? + +Una vez cerrado el issue que estabas asignado, serás anotado en la nómina para pagarte al final del mes. Normalmente entre el 28 del mes y el 5 del mes siguiente. Para más información de los pagos revise la sección de pagos + + +## Condiciones + +A pesar de ser un puesto de freelancer y que no tengas ninguna obligación dentro de la empresa, siempre recuerda que la responsabilidad, la honestidad y el compañerismo son cualidades de un desarrollador profesional, y serán valoradas por la empresa. Por otro lado, para mantener el orden y el respeto dentro de la empresa, no detener el flujo de trabajo ni afectar a los demás con nuestro trabajo, existen las siguientes condiciones: + +1. Para ser asignado a un issue siempre debes comentar el issue y pedir que se te asigne. Algún encargado asignará al primero que pida el issue siempre que no haya un motivo para no hacerlo. +2. Cada persona puede estar asignado a un máximo de 2 issues, así que primero concéntrate en los issues que ya tienes, para poder pedir algún otro que te guste. +3. Si una persona lleva más de 4 días asignado a un issue sin subir ningún Pull Request o interactuar, se le escribirá para ver el estado de la tarea, en caso de que el desarrollador no pueda hacerla por cualquier motivo, será desasignado para que otro tome la tarea. En caso de que el desarrollador sí pueda y quiera hacerla o ya tenga algo avanzado, se le darán unos días más para que termine el pull request. +4. Nunca debes hacer el push hacia la rama principal, siempre debes crear una rama individual desde la que trabajes los cambios requeridos para completar tu issue. +5. Si se nota algún comportamiento malicioso, como abusar de los permisos de escritor en el repositorio para desasignar a otros de sus tareas, cerrar issues que no estén completos, o intentar dañar pull requests de otros, etc... Será betado completamente de Azordev y no podrá trabajar con nosotros como Freelancer ni como Developer. +6. Tratamos de que sea un área amigable y donde todos se sientan seguros, por lo que el respeto será muy importante dentro de la comunicación en Azordev. + +## Negociación + +Estamos completamente abiertos a opiniones y comentarios acerca de las tareas y cómo mejorarlas. Un caso que puede darse, por ejemplo, es que una issue sea demasiado grande o la estimación de esfuerzo sea demasiado baja. En esos casos el desarrollador puede sugerir dividir las issues en varias partes o subirle la estimación de esfuerzo. + +Pueden conversar con nosotros acerca de cualquier cosa y nosotros lo consideraremos para mejorarlo. + +## FAQ + +### ¿Qué es el Code Review? + +El code review es una práctica que consiste en revisar los pull requests de tus compañeros para validar que todo esté correcto, muchas veces se dejan comentarios con buenas prácticas de código, consultando por ciertas líneas de código que sean confusas, y en general son con la intención de ayudar a mejorar el código entregado y probar la calidad o que funcione, antes de fusionarlo con la rama principal. \ No newline at end of file