Cambiar a contenido. | Saltar a navegación

gvSIG

Secciones

Herramientas Personales

Entrar

Usted está aquí: Inicio → Proyectos gvSIG → gvSIG Desktop → Documentación → Documentación de desarrollo → Cómo contribuir en gvSIG → Contribuciones y parches al código de gvSIG → Perfiles relacionados con la aportación de código

gvSIG Desktop

gvSIG Desktop

Cached time 11/21/13 07:54:14

Acciones de Documento

Perfiles relacionados con la aportación de código

por Joaquin Jose del Cerro Murciano — Última modificación 24/08/2012 12:11

Up one level

◄ Previous CLA status

Next: Modules gvSIG-desktop ►

Versión:	1.1

Tabla de contenidos

Introducción
Perfiles
Visibilidad de los perfiles
Deberes y derechos
Restricciones en la actividad
Metricas
Resumen de casos de uso y flujos de trabajo

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

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.