Latest revision as of 17:52, 16 June 2018

あなたが必要です！

LimeSurveyが素晴らしい製品だと思うなら、貢献してみませんか？

コードを書く必要はありません。テスター、翻訳者、サポーター、またはそのすべてになれます。歓迎します。または、ソースをちょっとハッキングして素晴らしい新機能を作ったり、このプロジェクトで将来の開発をしたいと思いませんか？私たちはあなたを愛しています！

LimeSurveyの開発者/翻訳者/チームメンバーになる方法

共通の要件

チームプレイヤー、素敵で丁寧な人。
他のチームメンバーと頻繁にコミュニケーションをとってください。開発ミーティングに出席してください。IRCチャンネル（[1]）に参加して、何が起こっているか見てください。
考えを共有してください。一人で考えないで、あなたのアイデアを他のチームメンバーと話し合ってください。
現実の人生が最優先です。参加できないときはどのぐらいになるか知らせてください。
開発者はオープンソースプロジェクトに出たり入ったりします。これは極めて普通のことです。ただ、プロジェクトを離れる場合は、どこまで進んだのか、何をしたのか、やるべきことがまだあるかどうか、他の誰かがあなたの仕事を続けることができるよう教えてください。
毎週火曜日、ベルリン時間14:30に開催される開発者会議に参加してください。会議は、irc.freenode.orgでチャンネルは#limesurvey-teamです（パスワードはCarsten Schmitzに聞いてください）。

最初のステップ

上記の点に同意する場合は、次の手順を実行してください。

limesurvey.orgのウェブサイトで個人アカウントを作成します（アカウントを持っていない場合）:[2]
gitHubで個人アカウントを作成します（アカウントを持っていない場合）:[3]
[4]でlimesurvey-developerメーリングリストに加入してください。開発ソースコードの変更を通知したい場合は、limesurvey-gitリストにも登録してください。
Windowsシステムを使用している場合は、GitクライアントのSmartGit（他にもありますが、これがおすすめです）を入手して、ソースコードgitHubにアクセスしてください。[5]からダウンロードできます。
limesurvey-developerのメーリングリストで自己紹介し、以下の情報を提供してください:
1. 簡単な履歴書（あなたの経歴が分かるように）
2. LimeSurveyプロジェクトで働く理由を教えてください（'退屈で死にそう'、'スタイルが好き...'とか）
3. サポートできる分野（コーディング、パッチ適用、サポートなど）を教えてください。
Carsten Schmitzができるだけ早く連絡します。彼はとても素敵な人で、手引きを与え、次のステップの詳細を提供します。
公式のLimeSurvey IRCチャンネルにアクセスし、声をかけてください！
([6])

新しい開発者のための追加情報

LimeSurveyには古くて混乱したコードがたくさん含まれていますが、今では非常に重要なコーディングガイドラインに厳密に従っています。

コーディングガイドラインと汎用コードの実装によって、後でコードを理解しやすくし、モジュール化を進めることになり、コーディングを行う開発者を支援します。

このような品質を確保するために、次の手順で新しい開発者を指導しています。

最初は新しい開発者に小さなタスクを割り当てます。どのタスクが割り当てるかは、新しい開発者と決定します。
開発者はレビューのためコードをメンターに送信します。
メンターがコード品質に満足すれば、開発者はコードをリポジトリーにコミットすることができます。
新しい開発者がパッチをリポジトリに自由に提出する準備が整った、とメンターが表明するまで、ステップ1から3を繰り返します。

新しい支持者のための追加情報

サポートするということは簡単なことではありません。友好的だったりそうでなかったり、厳格だったりいい加減だったり、熱心だったり落ち着いていたり、いろいろな人と関わるからです。

したがって、私たちは、チャンネルやフォーラムでサポートを提供する人に特別な要求をしています。

サポートで燃え尽きないでください。フォーラムで提起された技術的な質問のすべてにこたえるのはほぼ不可能です。多くの場合、問題は質問の技術的側面にはありません。コミュニケーションに文化的障壁が入ってきたり、初心者にどこから始めるか説明することは難しかったりするかもしれません。すべての質問に答えようとすると、サポート疲れに陥ります。
サポート疲れは、大抵、時間のコントロールができなくなった、とか、助けようと思った人が度を越した要求をしてきた、という気持ちが伴います。問題は、あまりにも多くの責任を負っていることにあります。ただ、問題は助けを求めたエンドユーザーにあることがわかってきます。
さまざまな人々がサポート疲れに反応し、さまざまな方法でサポートします。悪意のあるアドバイスをする人もいますし、初心者の質問にはURLやマニュアルの参照先リストで答えるべきだと主張する人もいます。
このような勝手なルールは、問題を現実には解決しないため、時間とともに肥大化します。すべての質問に答えることはできませんし、試みるべきでもありません。できる限り優しく、礼儀正しく、柔軟で、忍耐強く、親切であってほしいのですが、自分がイライラしているのがわかったら他のだれかに答えてもらうようにしましょう。超人的なサポートマシンになろうとしないでください。ユーザー同士の助け合いの余地も残してください。すべてのユーザーをサポートし、すべての質問に答えてしまうと、他のユーザーが助けたいと思う動機を奪ってしまうため、コミュニティーの意識を高めるとは限りません。

@@ Line 48: / Line 48: @@
 サポートするということは簡単なことではありません。友好的だったりそうでなかったり、厳格だったりいい加減だったり、熱心だったり落ち着いていたり、いろいろな人と関わるからです。
-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.
+*'''サポートで燃え尽きないでください'''。フォーラムで提起された技術的な質問のすべてにこたえるのはほぼ不可能です。多くの場合、問題は質問の技術的側面にはありません。コミュニケーションに文化的障壁が入ってきたり、初心者にどこから始めるか説明することは難しかったりするかもしれません。すべての質問に答えようとすると、サポート疲れに陥ります。<br />サポート疲れは、大抵、時間のコントロールができなくなった、とか、助けようと思った人が度を越した要求をしてきた、という気持ちが伴います。問題は、あまりにも多くの責任を負っていることにあります。ただ、問題は助けを求めたエンドユーザーにあることがわかってきます。<br />さまざまな人々がサポート疲れに反応し、さまざまな方法でサポートします。悪意のあるアドバイスをする人もいますし、初心者の質問にはURLやマニュアルの参照先リストで答えるべきだと主張する人もいます。<br />このような勝手なルールは、問題を現実には解決しないため、時間とともに肥大化します。すべての質問に答えることはできませんし、試みるべきでもありません。できる限り優しく、礼儀正しく、柔軟で、忍耐強く、親切であってほしいのですが、自分がイライラしているのがわかったら他のだれかに答えてもらうようにしましょう。超人的なサポートマシンになろうとしないでください。ユーザー同士の助け合いの余地も残してください。すべてのユーザーをサポートし、すべての質問に答えてしまうと、他のユーザーが助けたいと思う動機を奪ってしまうため、コミュニティーの意識を高めるとは限りません。

How to join the LimeSurvey project team/ja: Difference between revisions

From LimeSurvey Manual