How to join the LimeSurvey project team - Revision history

C schmitz at 08:28, 9 September 2022

2022-09-09T08:28:21Z

← Older revision		Revision as of 10:28, 9 September 2022
Line 1:		Line 1:
	~~<languages /> <translate>~~

	<!--T:1-->		<!--T:1-->
	__TOC__		__TOC__
Line 60:		Line 58:
	Therefore, we have a special request to persons who give support in the channel or forums:		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. <br />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.<br />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. <br />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.		*'''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. <br />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.<br />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. <br />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.

	~~</translate>~~

C schmitz: More link updates

2022-09-09T08:27:25Z

More link updates

C schmitz: Updated links from IRC to Discord

2022-09-09T08:26:04Z

Updated links from IRC to Discord

← Older revision		Revision as of 10:26, 9 September 2022
Line 35:		Line 35:
	## Tell us in what area you would like to help (coding, patching, support etc.)		## Tell us in what area you would like to help (coding, patching, support etc.)
	# 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.		# 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.
	# Visit ~~the~~ [~~http~~://~~www~~.~~limesurvey.org/en/community-services~~/~~live-chat official LimeSurvey IRC Channel~~] and SAY HELLO TO US!<br />~~([irc://irc.freenode.net/limesurvey])~~		# Visit our [https://discord.gg/DEjguXn Discord Server] and SAY HELLO TO US!<br />

	==Additional information for new developers== <!--T:9-->		==Additional information for new developers== <!--T:9-->

C schmitz at 08:25, 9 September 2022

2022-09-09T08:25:15Z

← Older revision		Revision as of 10:25, 9 September 2022
Line 16:		Line 16:
	==Common requirements== <!--T:6-->		==Common requirements== <!--T:6-->
	*Be a team player, nice & polite.		*Be a team player, nice & polite.
	*Communicate much and often with the other team members. Show up to the development meetings. Show up in our ~~IRC channel (~~[~~irc~~://~~irc~~.~~freenode.net~~/~~limesurvey~~]) to get a glimpse what is going on.		*Communicate much and often with the other team members. Show up to the development meetings. Show up in our [https://discord.gg/DEjguXn Discord Server] to get a glimpse what is going on.
	*Share your thoughts. Don't be single minded. Discuss your ideas with the other team members.		*Share your thoughts. Don't be single minded. Discuss your ideas with the other team members.
	*Real life comes first - but give us a small notice if and for how long you will be gone.		*Real life comes first - but give us a small notice if and for how long you will be gone.

Deusdeorum at 07:25, 10 January 2017

2017-01-10T07:25:23Z

← Older revision		Revision as of 09:25, 10 January 2017
Line 20:		Line 20:
	*Real life comes first - but give us a small notice if and for how long you will be gone.		*Real life comes first - but give us a small notice if and for how long you will be gone.
	*Developers come and go in an open source project - that is absolutely normal. However if you leave the project please give us a notice and tell us how far you are, what you did and if there are things still to do so that someone else can pick up your work.		*Developers come and go in an open source project - that is absolutely normal. However if you leave the project please give us a notice and tell us how far you are, what you did and if there are things still to do so that someone else can pick up your work.
	*Attend to the developers meeting which take place every Tuesday on 22:00 Berlin time on the channel #limesurvey-team on irc.freenode.org (ask Carsten Schmitz for the password - see below)		*Attend to the developers meeting which take place every Tuesday on 14:30 Berlin time in the channel #limesurvey-team on irc.freenode.org (ask Carsten Schmitz for the password - see below)

	==First steps== <!--T:7-->		==First steps== <!--T:7-->

Mbr at 20:53, 9 January 2017

2017-01-09T20:53:33Z

← Older revision		Revision as of 22:53, 9 January 2017
Line 20:		Line 20:
	*Real life comes first - but give us a small notice if and for how long you will be gone.		*Real life comes first - but give us a small notice if and for how long you will be gone.
	*Developers come and go in an open source project - that is absolutely normal. However if you leave the project please give us a notice and tell us how far you are, what you did and if there are things still to do so that someone else can pick up your work.		*Developers come and go in an open source project - that is absolutely normal. However if you leave the project please give us a notice and tell us how far you are, what you did and if there are things still to do so that someone else can pick up your work.
	*Attend to the developers meeting which take place every ~~Monday~~ on 22:00 Berlin time on the channel #limesurvey-team on irc.freenode.org (ask Carsten Schmitz for the password - see below)		*Attend to the developers meeting which take place every Tuesday on 22:00 Berlin time on the channel #limesurvey-team on irc.freenode.org (ask Carsten Schmitz for the password - see below)

	==First steps== <!--T:7-->		==First steps== <!--T:7-->

Nery at 00:23, 10 October 2013

2013-10-10T00:23:45Z

← Older revision		Revision as of 02:23, 10 October 2013
Line 40:		Line 40:

	<!--T:10-->		<!--T:10-->
	LimeSurvey contains ~~alot~~ of old and mess code - but by now we strictly pay attention to coding guidelines which are very important.		LimeSurvey contains a lot of old and mess code - but by now we strictly pay attention to coding guidelines which are very important.

	<!--T:11-->		<!--T:11-->

Nery at 00:22, 10 October 2013

2013-10-10T00:22:31Z

← Older revision		Revision as of 02:22, 10 October 2013
Line 47:		Line 47:
	<!--T:12-->		<!--T:12-->
	To ensure this quality we are mentoring new developers using the following steps:		To ensure this quality we are mentoring new developers using the following steps:
	# At first we only assign a small tasks to the new developer. What task is assigned will be decided together with the new developer.		# At first we only assign small tasks to the new developer. What task is assigned will be decided together with the new developer.
	# The developer sends the code to the mentor for review.		# The developer sends the code to the mentor for review.
	# If the mentor is satisfied with the code quality the developer may commit the code to the repository.		# If the mentor is satisfied with the code quality the developer may commit the code to the repository.

Han: link IRC changed

2013-09-04T11:16:48Z

link IRC changed

← Older revision		Revision as of 13:16, 4 September 2013
Line 35:		Line 35:
	## Tell us in what area you would like to help (coding, patching, support etc.)		## Tell us in what area you would like to help (coding, patching, support etc.)
	# 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.		# 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.
	# Visit the [http://www.limesurvey.org/~~index.php~~/~~Live~~-~~Chat.html~~ official ~~Lime Survey~~ IRC Channel] and SAY HELLO TO US!<br />([irc://irc.freenode.net/limesurvey])		# Visit the [http://www.limesurvey.org/en/community-services/live-chat official LimeSurvey IRC Channel] and SAY HELLO TO US!<br />([irc://irc.freenode.net/limesurvey])

	==Additional information for new developers== <!--T:9-->		==Additional information for new developers== <!--T:9-->

C schmitz: Text replace - "
" to "
"

2013-05-23T07:11:55Z

Text replace - "<br/>" to "<br />"

← Older revision		Revision as of 09:11, 23 May 2013
Line 35:		Line 35:
	## Tell us in what area you would like to help (coding, patching, support etc.)		## Tell us in what area you would like to help (coding, patching, support etc.)
	# 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.		# 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.
	# Visit the [http://www.limesurvey.org/index.php/Live-Chat.html official Lime Survey IRC Channel] and SAY HELLO TO US!<br/>([irc://irc.freenode.net/limesurvey])		# Visit the [http://www.limesurvey.org/index.php/Live-Chat.html official Lime Survey IRC Channel] and SAY HELLO TO US!<br />([irc://irc.freenode.net/limesurvey])

	==Additional information for new developers== <!--T:9-->		==Additional information for new developers== <!--T:9-->
Line 59:		Line 59:
	<!--T:15-->		<!--T:15-->
	Therefore we have a special request to persons who give support in the channel or forums:		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. <br/>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.<br/>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. <br/>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.		*'''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. <br />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.<br />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. <br />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.

	</translate>		</translate>

← Older revision		Revision as of 10:27, 9 September 2022
Line 16:		Line 16:
	==Common requirements== <!--T:6-->		==Common requirements== <!--T:6-->
	*Be a team player, nice & polite.		*Be a team player, nice & polite.
	*Communicate much and often with the other team members. Show up to the ~~development~~ meetings. Show up in our [https://discord.gg/DEjguXn Discord Server] to get a glimpse what is going on.		*Communicate much and often with the other team members. Show up to the team meetings. Show up in our [https://discord.gg/DEjguXn Discord Server] to get a glimpse what is going on.
	*Share your thoughts. Don't be single minded. Discuss your ideas with the other team members.		*Share your thoughts. Don't be single minded. Discuss your ideas with the other team members.
	*Real life comes first - but give us a small notice if and for how long you will be gone.		*Real life comes first - but give us a small notice if and for how long you will be gone.
	*Developers come and go in an open source project - that is absolutely normal. However if you leave the project please give us a notice and tell us how far you are, what you did and if there are things still to do so that someone else can pick up your work.		*Developers come and go in an open source project - that is absolutely normal. However if you leave the project please give us a notice and tell us how far you are, what you did and if there are things still to do so that someone else can pick up your work.
	*Attend to the ~~developers~~ meeting which take place every Tuesday on 14:30 Berlin time in the channel #limesurvey-team on ~~irc.freenode.org~~ (ask Carsten Schmitz for ~~the password~~ - see below)		*Attend to the team meeting which take place every Tuesday on 14:30 Berlin time in the channel #limesurvey-team on Discord (ask Carsten Schmitz for access - see below)

	==First steps== <!--T:7-->		==First steps== <!--T:7-->
Line 27:		Line 27:
	If you agree to the above points please follow these steps:		If you agree to the above points please follow these steps:
	#Create a personal account on the limesurvey.org website here (if you don't have one): [http://www.limesurvey.org/en/component/comprofiler/registers]		#Create a personal account on the limesurvey.org website here (if you don't have one): [http://www.limesurvey.org/en/component/comprofiler/registers]
	#Create a personal account on ~~gitHub~~ here (if you don't have one): [https://github.com/signup/free]		#Create a personal account on GitHub here (if you don't have one): [https://github.com/signup/free]
	#Make sure you subscribe to the limesurvey-developer mailing list at [http://sourceforge.net/p/limesurvey/mailman/?source=navbar]. If you want to get notified of any changes in the development source code then subscribe to the limesurvey-git list too.		#Make sure you subscribe to the limesurvey-developer mailing list at [http://sourceforge.net/p/limesurvey/mailman/?source=navbar]. If you want to get notified of any changes in the development source code then subscribe to the limesurvey-git list too.
	#If you use a Windows System get the Git client SmartGit (there are others but we recommend this one) to access the source code ~~gitHub~~. You can download it from [http://www.syntevo.com/smartgithg/]		#If you use a Windows System get the Git client SmartGit (there are others but we recommend this one) to access the source code GitHub . You can download it from [http://www.syntevo.com/smartgithg/]
	#Introduce yourself on the limesurvey-developer mailing list and provide the following information:		#Introduce yourself on the limesurvey-developer mailing list and provide the following information:
	## A short resume (so we can see what your background is)		## A short resume (so we can see what your background is)
Line 58:		Line 58:

	<!--T:15-->		<!--T:15-->
	Therefore we have a special request to persons who give support in the channel or forums:		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. <br />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.<br />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. <br />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.		*'''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. <br />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.<br />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. <br />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.

	</translate>		</translate>