Actions

How to join the LimeSurvey project team/nn

From LimeSurvey Manual

Revision as of 02:13, 14 April 2013 by C schmitz (talk | contribs) (Created page with "= Felles krav= * Vær en team player, fin og høflig. * Kommunisere mye og ofte med de andre gruppemedlemmene. Møt opp til utviklingssamtaler. Møt opp...")

Vi trenger deg!

Så .. du tror LimeSurvey er et flott produkt, og du ønsker å bidra med?

Hei, trenger du ikke å nødvendigvis skrive kode! Du også kan bli en tester, oversetter, tilhenger eller alle av det. Du er velkommen! Eller kanskje du hacket litt i kilden og opprettet en kjekk liten ny funksjon og / eller du ønsker å gjøre videre utvikling i dette prosjektet? Vi elsker deg!

Hvordan bli LimeSurvey utbygger / oversetter / team medlem?

Felles krav

  • Vær en team player, fin og høflig.
  • Kommunisere mye og ofte med de andre gruppemedlemmene. Møt opp til utviklingssamtaler. Møt opp i vår IRC-kanal ([irc: / / irc.freenode.net / limesurvey]) for å få et glimt hva som skjer.
  • Del dine tanker. Ikke bli ensrettet. Diskuter dine ideer med andre gruppemedlemmer.
  • Real livet kommer først - men gi oss en liten beskjed om og hvor lenge du vil være borte.
  • Utviklere kommer og går i et åpent kildekode-prosjekt - som er helt normalt. Men hvis du lar prosjektet vennligst gi oss en beskjed og fortell oss hvor langt du er, hva du gjorde og hvis det er ting fortsatt å gjøre slik at noen andre kan plukke opp arbeidet ditt.
  • Ivareta utviklerne møtet som finner sted hver tirsdag på 19:00 UTC på kanalen # limesurvey-dev på irc.freenode.org (spør Carsten Schmitz om passordet - se nedenfor)

First steps

If you agree to the above points please follow these steps:

  1. Create a personal account on the limesurvey.org website here (if you don't have one): [1]
  2. Create a personal account on sourceforge.net here (if you don't have one): [2]
  3. Make sure you subscribe to the limesurvey-developer mailing list at [3]. If you want to get notified of any changes in the development source code then subscribe to the limesurvey-csv list too.
  4. If you use a Windows System get the Subversion client TortoiseSVN to access the source code in the repository on sf.net. You can download it from [4]
  5. Introduce yourself on the limesurvey-developer mailing list and provide the following information:
    1. A short resume (so we can see what your background is)
    2. Tell us why you would like to work in the LimeSurvey project ('I am bored to death!', 'I like your style...') (:wink:)
    3. Tell us in what area you would like to help (coding, patching, support etc.)
  6. Carsten Schmitz will get back to you as soon as possible. He is a very nice guy and will give you an introduction and will provide more information on the next steps.
  7. Visit the official Lime Survey IRC Channel and SAY HELLO TO US!
    ([5])

Additional information for new developers

LimeSurvey contains alot of old and mess code - but by now we strictly pay attention to coding guidelines which are very important.

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.