Actions

How to join the LimeSurvey project team/es

From LimeSurvey Manual

Revision as of 02:10, 14 April 2013 by C schmitz (talk | contribs) (Created page with "== Información adicional para los nuevos soportistas==")

Te necesitamos!

Así que .. Crees que LimeSurvey es un gran producto y deseas contribuir?

Oye, no tienes que escribir necesariamente código! También podrías ser un  tester (pruebas de control de calidad), traductor, encargado de soporte. Para todas esas labores eres bienvenido! O tal vez podrías encontrar vulnerabilidades al código fuente, crear una ingeniosa característica nueva y / o te gustaría en el futuro desarrollar en este proyecto?

Si te interesa alguna de estas actividades, te queremos en el equipo!

Como te conviertes en un desarrollador  / traductor / miembro del equipo LimeSurvey?

Requisitos comunes!

  • Ser un jugador de equipo, de trato agradable y educado.
  • Comunicarte mucho y con frecuencia con los miembros del equipo. Participar de las reuniones de desarrollo. Participar de nuestro canal de IRC ([irc :/ / irc.freenode.net / limesurvey]) para echar un vistazo de lo que está sucediendo.
  • Debes compartir tus ideas. No ser individualista. Discutir tus ideas con los demás miembros del equipo.
  • La vida real es lo primero - pero siempre debes darnos un pequeño aviso si y por cuánto tiempo vas a estar ausente.
  • Los desarrolladores van y vienen en un proyecto de código abierto - eso es absolutamente normal. Sin embargo, si dejas el proyecto por favor nos das  aviso y nos dices cuan lejos vas a estar, lo que hiciste y si hay cosas por hacer para que otra persona pueda continuar tu obra.
  • Asistir a la reunión de desarrolladores que tienen lugar todos los martes a las 19:00 UTC en el canal # limesurvey-dev en irc.freenode.org (pregunta  a Carsten Schmitz por la contraseña - ver abajo por más detalles)

Tus primeros pasos!

Si estás de acuerdo con los apartados anteriores, sigue estos pasos:

  1. Crea una cuenta personal en el sitio web limesurvey.org aquí (si no tienes uno): [1]
  2. Crea una cuenta personal en sourceforge.net aquí (si no tienes uno): [2]
  3. Asegúrate de que estás suscrito a la lista de correo de desarrolladores de LimeSurvey-[3]. Si deseas ser notificado de cualquier cambio en el código fuente de desarrollo, entonces también suscribete a la lista limesurvey-csv.
  4. Si utilizas el sistema operativo Windows, obtén el cliente de Subversion TortoiseSVN para acceder al código fuente en el repositorio en sf.net. Lo puedes  descargar desde [4]
  5. Preséntate en la lista de correo limesurvey-desarrollador y proporciona la siguiente información:
  6. # Un breve curriculum (para que podamos conocer un poco de tu experiencia)
  7. # Dinos por qué te gustaría trabajar en el proyecto LimeSurvey («Estoy muy aburrido!", "Me gusta su manera de hacer las cosas ... ') (: guiño :)
  8. # Dínos en qué área te gustaría ayudar (codificación, parches, etc, soporte)
  9. Carsten Schmitz se pondrá en contacto contigo lo antes posible. Él es un tipo muy agradable y te dará una introducción y proporcionará más información sobre los pasos a seguir.
  10. Visita el sitio official Lime Encuesta IRC Channel !
    ([Irc :/ / irc.freenode.net / limesurvey])

Información adicional para los nuevos desarrolladores

LimeSurvey contiene una gran cantidad de código antiguo y desordenado - pero por ahora estrictamente  prestamos atención a las instrucciones de codificación, las cuales son muy importantes.

Las instrucciones de codificación y la aplicación de código genérico te ayudará a ti y a todos los desarrolladores a trabajar en su código en un momento posterior, con más fácil comprensión del código y permitirá hacerlo más modular.

Para garantizar esta calidad se está entrenando (guiados por un mentor) a los nuevos desarrolladores utilizando los siguientes pasos:

  1. Al principio nosotros sólo le asignamos algunas tareas pequeñas al nuevo desarrollador. ¿Qué tarea se le asigna será decidido junto con el mismo nuevo desarrollador.
  2. El programador envía el código al mentor para su revisión.
  3. Si el mentor está satisfecho con la calidad del código, el desarrollador puede grabar el código en el repositorio.
  4. Lave-enjuague y repita los pasos del 1 al 3 hasta que el mentor considere que el nuevo desarrollador está listo para grabar los parches libremente en el repositorio.

Información adicional para los nuevos soportistas

Giving support is a specialty since you are interacting with lots of different persons, friendly and not so friendly, strict or sloppy, eager or calm.

Therefore we have a special request to persons who give support in the channel or forums:

  • Don't be caught by support burnout.  It's nearly impossible to answer every technical question that is asked in the forum. In many cases, the problem doesn't lie in the technical aspects of the question; cultural barriers may get in the way of communication, or it may be difficult to explain to a newbie just where to begin. When you try to answer every question, regardless of difficulty, you set yourself up for support burnout.
    Support burnout is nearly always accompanied by the feeling that you're losing control of your time, that the people you've set out to help are making unreasonable demands. The problem is that you're taking on too much responsibility; but it begins to appear instead that the problem is the end user who's asking for help.
    Different people react to support burnout in different ways. Some offer malicious advice, some insist that every question a newbie asks should be answered with a URL or by lists of manual references.
    Such arbitrary rule sets tend to grow longer over time, because they don't solve the real problem. You can't answer every question, and you shouldn't try. Be gentle, be courteous, be flexible and be as patient and helpful as you can - but let someone else try to answer questions that you find too frustrating. Don't try to be a superhuman support machine. Also leave room for user-to-user help. If you support every user and answer every question you do not necessarily boost the community thinking because too much activity takes away any other user motivation to help.