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

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.

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.