Rahul Added Things a non Programmer can do.ja.md

docs/additional-material/Things a non Programmer can do.ja.md

@@ -0,0 +1,124 @@
+プログラマーでなくてもできること
+聞くことから始めよう
+
+オープンソースはすべて、他の人々を巻き込むことです。
+あなたはチームに加わろうとしており、それにはコミュニティとその仕組みを理解する必要があります。
+プロジェクトに参加して「こんにちは、このプロジェクトにはこうしたほうがいいと思います」と言うのは、通常あまり歓迎されません。
+一部のプロジェクトではそのようなアプローチを歓迎するかもしれませんが、長く続いているプロジェクトでは、その考え方はあまり受け入れられません。
+プロジェクトのニーズを理解するには、まず聞くことが最も重要です。
+
+1. メーリングリストに参加する
+
+多くのプロジェクトでは、メーリングリストが開発に関する主なコミュニケーション手段となっています。
+大規模なプロジェクトには、複数のメーリングリストがあります。
+たとえば、PostgreSQLプロジェクトには、少なくとも12のユーザー向けリストと6つの開発者リストがあります。
+主要なユーザー向けと開発者向けリストをフォローし、まずは「聞くこと」から始めましょう。
+2. ブログをフォローする
+
+主要な開発者が運営しているブログでは、今後のリリースや現在進行中の作業についての情報が得られます。
+Planetサイトは、関連する複数のニュースソースやブログ投稿を一か所でまとめて表示します。
+たとえば planet.gnome.org や planet.mysql.com のようなサイトがそうです。
+Googleで「Planet <プロジェクト名>」と検索してみましょう。
+
+3. IRCチャンネルに参加する
+
+多くのオープンソースプロジェクトにはIRC（インターネットリレーチャット）チャンネルがあり、開発者やユーザーが問題や開発について話し合っています。
+プロジェクトのWebサイトで、チャンネル名や使用しているIRCネットワークを確認しましょう。
+チケットを使った作業
+
+コードはオープンソースプロジェクトの中心ですが、貢献方法はそれだけではありません。
+コードの周囲のシステムの保守は、新機能の追加やバグ修正の際に見過ごされがちです。
+こうした分野に関わることは、プロジェクトへの入り口となります。
+多くのプロジェクトには、公開されているトラブルチケットシステムがあり、公式Webサイトのトップページやドキュメントからリンクされています。
+これはユーザーと開発者間の主なコミュニケーション手段です。これを最新に保つことは、大きな貢献となります。
+一部の操作には特別な権限が必要ですが、多くのプロジェクトリーダーは喜んで協力してくれます。
+
+4. バグの診断
+
+バグはしばしば不正確に報告されます。
+バグを診断して説明することは、開発者が問題の原因を特定する助けになります。
+たとえば「Xをしたときにソフトが動かない」と報告された場合、再現できるか確認しましょう。
+特定のブラウザでのみ発生するのか、特定のディストリビューションでのみ発生するのかを絞り込むことが重要です。
+原因が分からなくても、可能な限り情報を絞り込むことで他の人が修正しやすくなります。
+見つけたことはすべてチケットに記録しましょう。
+
+5. 修正されたバグを閉じる
+
+バグがコードで修正されても、チケットが更新されていないことがあります。
+このような「ごみ」を掃除するのは時間がかかりますが、プロジェクト全体にとっては非常に重要です。
+1年以上前のチケットを検索し、バグがまだ存在するか確認してください。
+リリースの変更ログを確認し、修正されたことが明らかであればチケットを閉じてください。
+バグが再現できなければそれを記録し、閉じます。再現できれば、続けてオープンにしておきます。
+コードを使った作業
+
+経験レベルに関係なく、誰でもコードで貢献できます。
+貢献するために天才である必要はありません。
+コードの修正を行う場合は、そのプロジェクトがどのようにコードを受け入れているか確認してください。
+各プロジェクトには独自のワークフローがあります。
+たとえば PostgreSQL ではパッチをメーリングリストに送る厳格なルールがありますが、Parrot のようなプロジェクトではもっと簡単です。
+GitHubを使用している場合は、Pull Requestを通じて貢献できます。
+修正時は、既存のコードスタイルに従い、責任あるメンバーとして行動してください。
+
+6. ベータ版やリリース候補版をテストする
+
+さまざまな環境で動作するソフトウェアには、移植性に関する問題が多く存在します。
+リリース前にベータ版やRC版が公開された際は、異なる環境でのテストが期待されます。
+あなたもその一員となり、自分の環境でビルド・実行・テストをして、動作報告を送りましょう。
+
+7. バグを修正する
+
+これはコードに貢献したい人のための一般的な方法です。
+チケットシステムから興味のあるバグを探し、修正に挑戦してください。
+テストが必要であれば、それも追加しましょう。
+修正できなかった場合でも、調査内容を記録することが次の人の助けになります。
+
+8. テストを書く
+
+ほとんどのプロジェクトにはテストスイートがありますが、十分にカバーされていないこともあります。
+テストカバレッジツールを使用して未カバー部分を探し、そこに対するテストを追加しましょう。
+
+9. コンパイラ警告を修正する
+
+多くのC系プロジェクトでは、ビルド時に警告が出ます。
+それらの多くは深刻な問題ではありませんが、見た目が悪く、重要な警告を埋もれさせてしまうことがあります。
+警告を解消するためのコード変更は、プロジェクトにとって役立ちます。
+
+10. コメントを追加する
+
+コードを読む中で混乱する箇所があれば、他の人も同じように困る可能性があります。
+そこにコメントを追加し、パッチとして提出しましょう。
+ドキュメントで貢献する
+
+ドキュメントはしばしば軽視されがちであり、経験者の視点で書かれていることが多いため、初心者にはわかりにくいことがあります。
+新しい視点から欠点を見つけ、改善することができます。
+
+11. 使用例を作成する
+
+どんなプロジェクトでも、How-toの使用例は歓迎されます。
+API、GUIアプリ、CLIツールなど、実用的な例を作りましょう。
+セットアップ手順のスクリーンショットを追加するのも良いアイデアです。
+コミュニティとの関わり方
+
+オープンソースはコードだけではありません。コミュニティこそがそれを支える柱です。
+
+12. 質問に答える
+
+他人を助けることは、コミュニティを強くする最高の方法です。
+特に初心者の質問に親切に答えることで、活発な参加者が増え、プロジェクトの将来が明るくなります。
+
+13. ブログ投稿を書く
+
+使っているソフトウェアに関して、経験や問題・解決策を書いてください。
+他のユーザーが同様の問題に直面したとき、あなたのブログが役立つかもしれません。
+また、将来そのソフトを使って職探しをする際の実績としても使えます。
+
+14. Webサイトを改善する
+
+もしWebデザインのスキルがあれば、プロジェクトのWebサイトを改善することで貢献できます。
+新しいロゴやバナー、レイアウトの改善など、あなたのスキルが生かされる場面は多くあります。
+
+最も重要なのは、周囲の人々がどんな話をしているのか、耳を傾けることです。
+必要なものに気づき、積極的に提案・行動することで、大きなインパクトを残すことができます。
+
+たとえば、Parrotの開発者がTracからGitHubへチケットを移行するか議論していた際、
+「コンバーターを書きましょうか？」と申し出たことで、450以上のチケットを失わずに済み、大きな成功となりました。