How to join the LimeSurvey project team/pt

We need you!

Então.. você acha LimeSurvey um grande produto e gostaria contribuir?

Ei, você não precisa necessariamente escrever códigos! Você pode ser um testador, tradutor, torcedor ou tudo isso. Você é bem-vindo! Ou talvez você enxugue um pouco a fonte e crie um ótimo recurso novo e/ou futuramente faça parte do desenvolvimento deste projeto? Nós te apoiamos!

Como se tornar um desenvolvedor LimeSurvey/tradutor/membro da equipe?

Requisitos Comuns

• Seja agradável e educado com a equipe.
• Comunique-se diversas vezes com os membros da equipe. Compareça às reuniões de desenvolvimento. Participe de nosso canal de IRC ([1]) para ter uma noção do que está acontecendo.
• Compartilhe suas ideias, não isole-as, não as esconda. Discuta-as com outros membros da equipe.
• A vida real vem em primeiro lugar, mas avise-nos por quanto tempo você estará disponível e/ou ausente.
• Desenvovledores entram e saem de projetos open source, isto é absolutamente normal. Mas se você deixar o projeto, por favor avise-nos informando-nos o que fez e em que ponto está para que outro contribuinte possa ajudar.
• Compareça ao encontro de desenvolvedores que ocorre toda terça-feira às 19:00 horas no canal # LimeSurvey-dev em irc.freenode.org (Solicite a Carsten Schmitz uma senha - veja abaixo)

Primeiro passo

Se você concorda com o que foi exposto até aqui, siga os seguintes passos:

1. Crie uma conta pessoal no limesurvey.org (Se você já não tem uma) acessando: [2]
2. Crie uma conta pessoal no sourceforge.net (se você já não tem uma) acessando: [3]
3. Certifique-se de assinar a lista de distribuição de desenvolvedores limesurvey em [4]. Se você quer ser notificado de quaisquer notificações no código-fonte, por desenvolvedores, assine também a lista csv.
4. Se você usa um sistema Microsoft Windows, procure um cliente TortoiseSVN para acessar o código-fonte no repositório sf.net. Você pode baixá-lo [5]
5. Apresente-se na lista de discussão de desenvolvedores LimeSurvey e forneça:
   1. Um pequeno resumo de você (para que possamos te conhecer um pouco mais)
   2. Informe-nos por que você gostaria de trabalhar no projeto LimeSurvey ("Eu estou entediado até a morte! ',' Eu gosto do seu estilo ...')
   3. Conte-nos em que área você gostaria de ajudar (codificação, aplicação de patches, suporte, etc)
6. Carsten Schmitz voltará o mais breve possível. Ele é um cara muito legal e te dará uma introdução fornecendo mais informações sobre os próximos passos.
7. Visite o Canal IRC oficial do Lime Survey e dê um Olá para nós!
   ([6])

Informações adicionais para novos desenvolvedores

LimeSurvey tem um monte de código velho e confuso - mas estamos rigorosamente atentos a diretrizes de codificação que são muito importantes.

Coding Guidelines and Generic Code Implementation will help you and any developers working on your code at a later time by easier understanding your code and making it more modular.

To ensure this quality we are mentoring new developers using the following steps:

1. At first we only assign a small tasks to the new developer. What task is assigned will be decided together with the new developer.
2. The developer sends the code to the mentor for review.
3. If the mentor is satisfied with the code quality the developer may commit the code to the repository.
4. Rinse and repeat Step 1 to 3 until the mentor states that the new developer is ready to submit patches freely to the repository.

Additional information for new supporters

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.