Document Actions
Perfiles relacionados con la aportación de código
:Versión: 1.1
.. contents:: Tabla de contenidos
Introducción
===============
El objetivo de este documento es definir cada uno de los actores o perfiles que están involucrados en el desarrollo de gvSIG.
Los perfiles descritos son:
- Desarrollador externo
- Desarrollador del proyecto
- Mantenedor
- Revisor
- Tester
- Soporte de arquitectura
Perfiles
=======================
Desarrollador externo
-----------------------
Se trata de cualquier persona de la comunidad interesada en aportar un parche.
No tiene una vinculación fuerte con el proyecto y se pretende que pueda realizar pequeñas aportaciones de código
sin que se encuentre demasiadas trabas para hacerlo.
Desarrollador del proyecto
---------------------------
Es un desarrollador con permiso de escritura en parte o todo el repositorio de fuentes de gvSIG. De esta forma, por ejemplo, a petición del mantenedor de un módulo,
podrá encargarse de subir los parches enviados por un desarrollador externo. Tiene vinculación fuerte con el proyecto, realiza aportaciones de código al proyecto de forma más o menos continuada.
Para optar a este perfil, se presentará petición al board para su estudio y aprobación por mayoría simple siempre que cumpla con
las métricas establecidas. Si no cumple con las métricas establecidas la aprobación deberá ser por mayoría cualificada de 3/4.
Este perfil se podrá perder si se presenta al board una petición para su estudio. La decisión se realizará en función de las métricas
establecidas y con el mismo criterio por el que se permite otorgar el perfil.
Mantenedor
---------------------------
Es el principal responsable de realizar las labores de coordinación en un subsistema. Podrán tratar tickets de desarrolladores externos o derivarlos hacia desarrolladores del proyecto.
Por otra parte, desde un punto de vista técnico, velará por mantener una alta cohesión y un bajo acoplamiento en los subsistemas en los que es reponsable.
En cuanto al mecanismo para optar a este perfil, de la misma forma que para los desarrolladores del proyecto, se presentará una petición al board para su estudio. El board, en función de las métricas que miden las capacidades del candidato, podrá aceptar el candidato por mayoría simple. Aún si las métricas no pueden evaluar el candidato, este podrá ser aceptado por mayoría cualificada de 3/4. Para la pérdida del perfil se seguirá el mismo criterio.
Revisor
---------------------------
Es el encargado de supervisar y evaluar los cambios que se producen en los subsistemas ya sea por petición expresa de un mantenedor o a través de tareas periódicas de supervisión.
Su objetivo es mantener la estabilidad y robustez de la aplicación en su conjunto prestando especial atención a los interfaces de los subsistemas y a las colaboraciones entre ellos.
Se trata de un desarrollador con una especial sensibilidad que le lleva a mirar con ojo crítico el código a subir al repositorio de fuentes, mirando más por el impacto que pueden tener los cambios que por la utilidad de la funcionalidad que aportan
Este perfil no requiere tener un conocimiento especifico del modulo sobre el que se quieren aplicar los cambios que ha de revisar ni un conocimiento profundo de la arquitectura de gvSIG, y no estarían asignados a un modulo, proyecto o subsistema dentro de gvSIG.
Una aclaración importante sobre el revisor, este no es nunca la pieza de apoyo para el mantenedor de un modulo o subsistema en ningún sentido.
Tanto para adquirir la condición de revisor como para perderla, se seguirán los mismos criterios que para el mantenedor, es decir, someter a votación en el board la adquisición o revocación del perfil tomando como base unas métricas que permitan evaluar el candidato.
Tester
----------------------------
.. note:: La información sobre el tester no esta completa, solo en la medida que parece relevante en su relación con los otros roles que aparecen en este documento
El tester es el encargado de verificar que la aplicación funciona conforme a las instrucciones definidas en el ticket. En caso de que se trate de una corrección de un error, en el ticket deberá estar incluido, además del código, toda la información relativa a cómo reproducir el error y cómo verificar que este ha sido corregido.
En caso de tratarse de una nueva funcionalidad deberá incluir una descripción de los requerimientos de esta y cómo el tester puede comprobar que los cumple.
Para optar a este perfil, actualmente, basta con la aprobación del responsable de testeo.
Soporte de arquitectura
----------------------------
Se trata de un miembro del grupo de arquitectura de gvSIG al que se puede dirigir cualquier desarrollador para pedir consejo o ayuda a la hora de evaluar el impacto de un determinado cambio.
Visibilidad de los perfiles
============================
Cada uno de los actores encargados de modificar y revisar el código de gvSIG tienen una visibilidad distinta del proyecto, ya sea una visibilidad de alto nivel o de detalle. Por ejemplo, una visibilidad de alto nivel verá el código de gvSIG como un conjunto de subsistemas que colaboran a través de unos interfaces bien definidos. Una visibilidad de bajo nivel tratará el código desde una perspectiva más enfocada a la implementación de los subsistemas. Con esta definición en mente, la siguiente tabla muestra la visibilidad con la que percibe el código los principales actores:
+--------------------------+--------------------------------------------------------------------------------------------+
| Perfil | Visibilidad |
+==========================+============================================================================================+
| **Soporte arquitectura** | Tiene una visión general de la aplicación, viendo esta en su conjunto. |
+--------------------------+--------------------------------------------------------------------------------------------+
| **Mantenedor** | Tiene una visión de la aplicación restringida al módulo o subsistema del que es mantenedor,|
| | así como de los APIs de los módulos con los que interactúa |
+--------------------------+--------------------------------------------------------------------------------------------+
|**Revisor** | Tiene una visión de interface o incluso método. Evalúa el impacto que tienen cambios en la |
| | semántica, interfaces, signaturas de un método o el ámbito de estos. |
+--------------------------+--------------------------------------------------------------------------------------------+
Deberes y derechos
============================
A continuación se detallan los deberes y los derechos de cada uno de los perfiles:
+--------------------------------+---------------------------------------------------------------------------------------+
| Perfil | Deberes y derechos |
+================================+=======================================================================================+
| **Desarrollador externo** | - Puede dar de alta tickets adjuntando parches a estos. |
| | - Debe conocer las `recomendaciones y procedimientos para enviar un parche`_ |
| | - Debe conocer las `normas de codificación que usa el proyecto`_ |
| | - Debe actualizar los *javadocs* si sus cambios modifican el API |
| | - Debe actualizar los test unitarios si estos dejan de funcionar debido a sus cambios |
| | - A petición de un mantenedor, deberá actualizar o crear los test unitarios |
| | correspondientes para poder testear sus cambios |
| | - Debe incluir información de cómo testear los cambios por parte de un usuario |
| | - Si el cambio afecta al interfaz de usuario, el mantenedor puede solicitar las |
| | modificaciones correspondientes en el manual de usuario |
+--------------------------------+---------------------------------------------------------------------------------------+
| **Desarrollador del proyecto** | - Puede dar de alta tickets adjuntando parches o referencias a revisiones del SVN |
| | - Puede subir código al SVN (siempre asociado a un ticket que tiene asignado) |
| | - Debe conocer las `recomendaciones y procedimientos para enviar un parche`_ |
| | - Debe conocer las `normas de codificación que usa el proyecto`_ |
| | - Debe estar informado de la fase en la que se encuentra el proyecto. Hay fases de |
| | estabilización en la que no se pueden subir cambios al SVN. Estas fases son |
| | notificadas a los desarrolladores a través de las listas de correo públicas |
| | - Debe estar al corriente de la `documentación de desarrollo`_. |
| | - Debe actualizar la información de los _javadocs_ afectados por sus cambios |
| | - Debe actualizar los test unitarios si estos dejan de funcionar debido a sus cambios |
| | - Debe actualizar los test unitarios existentes si sus cambios afectan a código que |
| | debería estar testeado y no está cubierto en ese momento |
| | - Debe suministrar a los testers toda la información que necesiten para validar el |
| | cambio y actualizar los casos de prueba relacionados con él (Nota: actualmente no |
| | es posible debido a la herramienta que estamos usando, cuando los impedimentos |
| | técnicos desaparezcan deberá hacerse). |
| | - Si el cambio afecta al interfaz de usuario, el mantenedor puede solicitar las |
| | modificaciones correspondientes en el manual de usuario |
+--------------------------------+---------------------------------------------------------------------------------------+
| **Mantenedor** | - Tiene los mismos derechos y obligaciones que cualquier otro desarrollador |
| | - Puede dar de alta tickets adjuntando parches o referencias a revisiones del SVN |
| | - Puede subir código al SVN (siempre asociado a un ticket que tiene asignado) |
| | - Puede asignar tickets a revisores |
| | - Puede consultar con soporte arquitectura sobre el impacto de un cambio en el código |
| | - Puede asignar tickets a desarrolladores para que suban los cambios al SVN o para |
| | que pidan mas información al que suministró el código. Esto no elimina la revisión, |
| | simplemente agiliza esta cuando se vaya a llevar a cabo. |
| | - Puede asignarse un ticket con parche para subir los cambios al SVN |
| | - Debe dar curso a los tickets que se han recibido en relación al subsistema que |
| | mantiene (asignación de tickets a revisores para su revisión o desarrolladores del |
| | proyecto para su realización) |
| | - Debe asegurarse que los tickets tengan toda la información que necesiten los testers|
| | para validar el cambio, y caso contrario deberá solicitar dicha información al |
| | desarrollador que aportó la solución. |
| | - Debe rechazar los tickets que no aporten la documentación en forma de javadocs al |
| | código nuevo que se introduzca o modifique (si tras solicitar al desarrollador su |
| | correccion este no puede realizarla). |
| | - Debe rechazar los tickets que provoquen que los tests automatizados existentes en el|
| | proyecto al que van dirigidos dejen de pasar (si tras solicitar al desarrollador su |
| | corrección este no puede realizarla). |
| | - Debe rechazar los tickets con aportaciones de código que no cumplan con las normas |
| | de codificación del proyecto (si tras solicitar al desarrollador su corrección este |
| | no puede realizarla). |
| | - Debe rechazar los tickets con aportaciones de código que no especifiquen cómo puede |
| | el tester verificar que funciona correctamente (si tras solicitar al desarrollador |
| | su corrección este no puede realizarla). |
| | - Debe mantener la configuración, información y documentación del proceso de |
| | construcción de su subsistema. Si se emplea maven, asegurarse que, además de |
| | compilar, funcionan correctamente los mecanismos de deploy, generación de site, |
| | release, etc., así como la información contenida en el archivo pom.xml como: |
| | desarrolladores, descripción, etc. |
| | - Debe responsabilizarse de la aplicación de correcciones y nuevas funcionalidades |
| | entre las distintas versiones vivas de gvSIG, como mínimo siempre hacia versiones |
| | superiores. No es necesario que aplique o pida directamente los cambios en todas las|
| | versiones, pero como mínimo dé de alta los tickets correspondientes para que los |
| | cambios no queden en el olvido. Por ejemplo, un bug con parche para la rama 1.x, |
| | debería ser aplicado o al menos crear el ticket correspondiente para la 2.x. |
| | - Debe resposabilizarse de las versiones del susbsistema. |
| | - Debe coordinar los cambios para que estén disponibles en las revisiones de la |
| | aplicación. |
| | - Debe estar al corriente de la arquitectura del sistema, sobre todo de los |
| | subsistemas de los que depende. |
| | - Debe mantener actualizada la documentación de usuario solicitando la información |
| | adicional o las capturas necesarias al emisor del ticket. |
| | - Debe mantener actualizada y desplegada correctamente la documentación de desarrollo |
| | solicitando la información adicional o las capturas necesarias al emisor del ticket.|
| | - Debe conocer los `procedimientos asociados a la generación de manuales de usuario |
| | del proyecto`_. |
+--------------------------------+---------------------------------------------------------------------------------------+
| **Revisor** | - Puede dar de alta tickets adjuntando parches o referencias a revisiones del SVN |
| | - Puede subir código al SVN (siempre asociado a un ticket que tiene asignado) |
| | - Puede aceptar o rechazar un ticket con código |
| | - Puede consultar con soporte arquitectura sobre el impacto de un cambio en el código |
| | - Puede consultar con un mantenedor cuando el cambio este estrechamente ligado a un |
| | subsistema del que hay mantenedor. |
| | - Puede corregir pequeños problemas que cause la inclusión del código comunicándolo en|
| | el ticket. |
| | - Debe revisar los tickets marcados para revisión y que le han sido asignados. |
| | - Debe reportar en el mismo ticket cualquier deficiencia que haya sido detectada |
| | - Debe rechazar los tickets que provoquen que dejen de funcionar los test |
| | automatizados |
| | - Debe rechazar los tickets que no aporten la documentación en forma de javadocs al |
| | código que introduzcan o modifiquen. |
| | - Debe rechazar los tickets con aportaciones de código que no cumplan con las normas |
| | de codificación del proyecto. |
| | - Debe rechazar los tickets con aportaciones de código que no especifiquen cómo puede |
| | el tester verificar el correcto funcionamiento. |
| | - Debe comunicar al mantenedor correspondiente si no puede hacerse cargo de una |
| | revisión solicitada |
+--------------------------------+---------------------------------------------------------------------------------------+
| **Tester** | - Puede marcar un ticket como resuelto. |
| | - Puede marcar un ticket como incorrecto. |
| | - Puede marchar un ticket como validado. |
| | - Debe verificar los tickets que le asigne el responsable de testing y marcarlos como |
| | validados, no corregidos, o pendientes de mas información |
+--------------------------------+---------------------------------------------------------------------------------------+
| **Soporte arqutectura** | - Puede asignar tickets para que sean revisados. |
| | - Debe asignar tickets asociados a módulos sin mantenedor para que sean revisados |
| | durante los periodos de estabilización |
| | - Debe responder ante cualquier duda planteada sobre la arquitectura de la aplicación |
+--------------------------------+---------------------------------------------------------------------------------------+
.. _`recomendaciones y procedimientos para enviar un parche` : http://www.gvsig.org/web/reference_catalog/lookupObject?uuid=b49f9501f8f5740cb3d3d1a5e1b53778
.. _`normas de codificación que usa el proyecto` : http://www.gvsig.org/web/reference_catalog/lookupObject?uuid=6f1351515e78c0259c38672b3ffce164
.. _`documentación de desarrollo` : http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel
.. _`procedimientos asociados a la generación de manuales de usuario del proyecto` : http://www.gvsig.org/web/reference_catalog/lookupObject?uuid=55653a0583dd9a9cd5571ca4203959a3
Restricciones en la actividad
===============================
La siguiente tabla enumera algunas restricciones que se aplican a cada uno de los perfiles:
+---------------------------------+--------------------------------------------------------------------------+
| Perfil | Restricciones |
+=================================+==========================================================================+
| **Desarrollador externo** | - No puede subir código directamente al repositorio de fuentes. |
| | - No puede aprobar un ticket de aporte de código. |
| | - No puede asignarse a sí mismo un ticket. |
| | - No puede validar un ticket. |
+---------------------------------+--------------------------------------------------------------------------+
| **Desarrollador del proyecto** | - No puede aprobar un ticket de aporte de código. |
| | - No puede validar un ticket. |
| | - No puede asignar tickets. |
+---------------------------------+--------------------------------------------------------------------------+
| **Mantenedor** | - No puede marcar un ticket como revisado con aportaciones de código de |
| | él mismo. |
+---------------------------------+--------------------------------------------------------------------------+
| **Revisor** | - No puede tomar decisiones relacionadas con la funcionalidad a la hora |
| | de aceptar código |
| | - No puede revisar tickets suyos |
| | - No puede subir código de un ticket sin que este se le haya asignado por|
| | parte del mantenedor del módulo o el grupo de arquitectura |
+---------------------------------+--------------------------------------------------------------------------+
Metricas
===============================
A continuación se detallan las distintas métricas que se tendrán en cuenta a la hora de optar por un perfil:
+---------------------------------+------------------------------------------------------------------------------------------------+
| Perfil | Consideraciones (adquirir perfil) |
+=================================+================================================================================================+
| **Desarrollador del proyecto** | - Haber aportado al menos tres parches de código. |
| | - Haber aportado código al menos en dos revisiones de gvSIG. |
| | - Haber al menos dos revisores, mantenedores o miembros del equipo de arquitectura que |
| | presenten y respalden la petición, teniendo especial peso la visión de los revisores que han |
| | participado activamente en la admisión de parches de este desarrollador. |
+---------------------------------+------------------------------------------------------------------------------------------------+
| **Mantenedor** | - Debe de haber sido desarrollador del proyecto durante al menos el periodo que va de una |
| | revisión a otra de gvSIG. |
| | - Debe de haber colaborado de forma activa en el subsistema del que quiere ser mantenedor, |
| | habiendo aportado al menos 6 parches al modulo que desea mantener. |
| | - Deberán haber al menos un revisor, mantenedor o miembro del equipo de arquitectura que |
| | presente y respalde la petición, teniendo especial peso los revisores que han participado |
| | activamente en la revisión de tickets de este candidato. |
+---------------------------------+------------------------------------------------------------------------------------------------+
| **Revisor** | - Debe de haber sido desarrollador del proyecto durante al menos el periodo que va de una |
| | revisión a otra de gvSIG. |
| | - Deberá haber al menos un revisor, mantenedor o miembro del equipo de arquitectura que |
| | presente y respalde la petición, teniendo especial peso los revisores que han participado |
| | activamente en la revisión de tickets de este candidato. |
+---------------------------------+------------------------------------------------------------------------------------------------+
En esta otra tabla se muestran las distintas consideraciones a tener en cuenta para solicitar la pérdida de un perfil:
+---------------------------------+------------------------------------------------------------------------------------------------+
| Perfil | Consideraciones (perder perfil) |
+=================================+================================================================================================+
| **Desarrollador del proyecto** | - Haber realizado cuatro o más aportaciones de código al repositorio de fuentes consecutivas |
| | que son rechazadas tras su revisión, ya sea por parte de los mantenedores del subsistema |
| | implicado o por un revisor. |
| | - Por descuido reiterado en las aportaciones que ocasionen otros errores en la aplicación. |
| | - Después de un periodo de inactividad de dos años. |
| | - Si hay una desvinculación clara con el proyecto |
+---------------------------------+------------------------------------------------------------------------------------------------+
| **Mantenedor** | - Realizar cuatro o más aportaciones de código al repositorio de fuentes consecutivas que son |
| | rechazadas tras su revisión, ya sea por un revisor o un miembro del equipo de arquitectura. |
| | - Después de un periodo de inactividad de dos años. |
| | - Si hay una desvinculación clara con el proyecto. |
| | - Si se realizan cuatro o más aportaciones únicamente a un submódulo de una versión, sin su |
| | correspondiente aplicación o ticket a versiones superiores. |
+---------------------------------+------------------------------------------------------------------------------------------------+
| **Revisor** | - Aceptar cuatro o más revisiones de código consecutivas que el equipo de arquitectura |
| | considere que ha alterado el API en su sintaxis o semántica y esto pueda afectar al |
| | funcionamiento de otras partes de la aplicación. |
| | - Después de un periodo de inactividad de dos años. |
| | - Si hay una desvinculación clara con el proyecto. |
| | - Si hay un descuido en sus obligaciones de forma clara y reiterada. |
+---------------------------------+------------------------------------------------------------------------------------------------+
Resumen de casos de uso y flujos de trabajo
============================================
.. warning:: En construcción
Caso 1: Alta de ticket con parche
----------------------------------
- Se da de alta el ticket con la descripción del bug o la nueva funcionalidad.
- Un desarrollador añade el parche con el código.
- Si el ticket lo va a gestionar un revisor
- El mantenedor o miembro del equipo de arquitectura asigna el ticket a un revisor
- Si el revisor observa algo que no le parece adecuado, informa de ello en el ticket y si ve que puede ser arreglado lo pierde a través de el para que lo atienda el desarrollador que aporto el parche.
- Cuando el revisor ve que todo esta bien, sube los cambios al SVN y actualiza el ticket marcándolo como revisado.
- Si el ticket lo va a gestionar el mantenedor
- El mantenedor o miembro del equipo de arquitectura asigna el ticket a al mantenedor
- El mantenedor sube los cambios al SVN y actualiza el ticket.
- El mantenedor o miembro del equipo de arquitectura asigna el ticket a un revisor
- Si el revisor observa algo que no le parece adecuado, informa de ello en el ticket y si ve que puede ser arreglado lo pide a través de el para que el mantenedor lo atienda.
- Cuando el revisor ve que todo esta bien actualiza el ticket marcándolo como revisado.
- Si el ticket lo va a gestionar un desarrollador del proyecto.
- El mantenedor o miembro del equipo de arquitectura asigna el ticket a al desarrolador del proyecto
- El desarrollador sube los cambios al SVN y actualiza el ticket.
- El mantenedor o miembro del equipo de arquitectura asigna el ticket a un revisor
- Si el revisor observa algo que no le parece adecuado, informa de ello en el ticket y si ve que puede ser arreglado lo pide a través de el para que el desarrollador lo atienda.
- Cuando el revisor ve que todo esta bien actualiza el ticket marcándolo como revisado.
Caso 2: Resolución de un ticket por un desarrollador del proyecto
------------------------------------------------------------------
- El desarrollador se pondrá en contacto con el mantenedor del proyecto, en primera instancia a través de un comentario en el ticket haciéndole saber que esta interesado en gestionarlo.
- El mantenedor asigna el ticket al desarrollador.
- El desarrollador sube los cambios al SVN y actualiza el ticket.
- El mantenedor o miembro del equipo de arquitectura asigna el ticket a un revisor.
- El revisor realiza la revisión del código y marca como revisado el ticket
Caso 3: Resolución de un ticket por un mantenedor
--------------------------------------------------
- El mantenedor se asignará el ticket a sí mismo.
- El mantenedor sube los cambios y actualiza el ticket.
- El mantenedor o miembro del equipo de arquitectura asigna el ticket a un revisor.
- El revisor realiza la revisión del código y marca como revisado el ticket.
.. list-table:: Registro de cambios
:header-rows: 1
* - versión
- Descripción
* - 1.1
- Añadida información sobre flujo de trabajo (por revisar)
