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

# プログラマーでない人ができること
## 聞くことから始める

オープンソースに関わる全てのことは、他の人との関わりを伴います。  
あなたはチームに参加しようとしているわけで、それはコミュニティやその仕組みを理解することを意味します。  
プロジェクトに入って「こんにちは、このプロジェクトはこうあるべきだと思います」といきなり言うのは、通常あまり歓迎されません。  
もちろん、そういうアプローチを歓迎するプロジェクトもありますが、プロジェクトがある程度運営されている場合、その態度が受け入れられる可能性は低いです。  
**聞くことこそ、プロジェクトが本当に必要としていることを知る最良の方法です。**

1. **メーリングリストに参加する**: 多くのプロジェクトでは、メーリングリストがプロジェクト開発に関する主なコミュニケーション手段です。  
大規模なプロジェクトでは、選択できるメーリングリストが複数あります。  
例えば、PostgreSQLプロジェクトでは、ユーザー向けリストが12件以上、開発者向けリストが6件も存在します。  
まずはメインのユーザー向けリストとコア開発者向けリストをフォローして、内容を追ってみることから始めることをお勧めします。

2. **ブログをフォローする**: コア開発者が運営するブログは、今後のリリースで何が起こるのか、そしてそこに至るまでに何が必要だったかを教えてくれます。  
「Planetサイト」は、プロジェクトに関連する様々なニュースやブログ記事を集約しています。  
もし planet.gnome.org や planet.mysql.com のような Planet サイトがあれば、まずそこから始めましょう。  
Googleで「planet <projectname>」と検索するだけでも見つかります。

3. **IRCチャンネルに参加する**: 多くのオープンソースプロジェクトには、開発者やユーザーが集まって問題や開発について話し合う専用のIRCチャンネルがあります。  
プロジェクトのウェブサイトで、チャンネル名やどのIRCネットワークにあるかを確認してください。

## チケットを扱う
コードはオープンソースプロジェクトの中心ですが、コードを書くことだけが貢献方法ではありません。  
コードやコード周辺のシステムのメンテナンスは、新機能の作成やバグ修正の急ぎでおろそかにされがちです。  
こうした領域は、プロジェクトに足を踏み入れる簡単な方法となります。  
ほとんどのプロジェクトには、プロジェクトのウェブサイトのトップページやドキュメントにリンクされた公開チケットシステムがあります。  
それはユーザーと開発者の間の主要なコミュニケーション手段です。最新の状態を維持することは、プロジェクトを助ける優れた方法です。  
チケットシステムで特別な権限が必要になる場合がありますが、ほとんどのプロジェクトリーダーは「チケットを整理して手伝いたい」と言えば喜んで権限を与えてくれます。

4. **バグを診断する**: バグ報告はしばしば不十分です。  
バグを診断し、優先順位を付けることで、開発者が問題の詳細を把握する手間を省くことができます。ユーザーが「Xをしたらソフトが動かない」と報告した場合、その問題を引き起こす具体的な条件を時間をかけて特定してみましょう。再現性はあるか？問題を繰り返し起こる手順を作れるか？特定のブラウザでのみ発生する、あるいは特定のディストリビューションでのみ起こるなど、問題を絞り込めるか？原因が分からなくても、条件を絞り込む努力は、誰かが修正する際に役立ちます。  
発見したことはすべてチケットに記録して、他の人も参照できるようにしましょう。

5. **修正済みバグを閉じる**: バグはコード上で修正されても、チケットシステムで更新されないことがあります。こうした未整理のチケットを整理するのは時間がかかりますが、プロジェクト全体にとって価値があります。まずはチケットシステムで1年以上前のチケットを検索し、そのバグがまだ存在するか確認します。プロジェクトのリリース変更ログをチェックして、バグが修正され閉じられるべきか確認します。修正済みであれば、チケットにバージョン番号を記載して閉じます。 最新バージョンのソフトウェアでバグを再現できるか試してください。再現できなければ、チケットにその旨を記録して閉じます。まだ存在する場合は、そのこともチケットに記録して、開いたままにします。

## コードに取り組む

あらゆる経験レベルのプログラマーは、プロジェクトのコードに貢献できます。  
自分が好きなプロジェクトに本当に貢献するために、コーディングの天才である必要はありません。

コードを修正する場合、プロジェクトが採用している、コントリビューターからコードを取得する方法を調べましょう。  
各プロジェクトには独自のワークフローがあるため、コードを提出する前に確認することが重要です。

例えば、PostgreSQLプロジェクトでは非常に厳密なプロセスがあり、コード修正はパッチ形式でメーリングリストに送られ、コア開発者が変更のすべてを精査します。  
一方、Parrotのようにコードベースへのコミット権限を簡単に得られるプロジェクトもあります。  
プロジェクトがGitHubを使っている場合、GitHubのプルリクエスト機能を使ったワークフローがあるかもしれません。  プロジェクトごとに方法は異なります。

コードを修正するときは、コミュニティの責任あるメンバーとして行動し、コードスタイルを既存のコードベースに合わせましょう。  
追加・修正するコードは既存コードと同じように見えるべきです。  
中括弧のスタイルやインデントのスペースの扱いが好みでなくても、既存の標準に合わないコード変更を提出するのは失礼です。  
「自分のスタイルが正しい」と押し付けることと同じです。

6. **ベータ版やリリース候補をテストする**: 複数のプラットフォームで動作するプロジェクトは、移植性に関する様々な問題を抱える可能性があります。  
リリースが近づき、ベータ版やリリース候補が公開されたら、多くの人にテストしてもらうことがプロジェクトリーダーの望みです。  
あなたもその一人として、自分の環境で動作を確認し、貢献できます。通常はソフトウェアをダウンロードしてビルドし、テストするだけで十分ですが、珍しいディストリビューションやハードウェアでのテスト結果は非常に価値があります。  
ビルドやテストが成功したことを報告するだけでも、リリースが安定しているかどうかの判断材料になります。

7. **バグを修正する**: コードに取り組みたい貢献者は通常ここから始めます。  
やることはシンプルです: チケットシステムで興味のあるバグを見つけ、コードで修正を試みます。  
修正内容は適宜コード内に文書化しましょう。  
修正箇所をテストスイートに追加してテストするのも良い考えです。  
プロジェクトによっては、バグ修正にはテスト追加が必須の場合があります。  
初めて触れるコードベースを調べながらメモを取りましょう。  
バグを修正できなくても、修正試行の過程で分かったことをチケットに記録すれば、後から来る人に役立ちます。

8. **テストを書く**: ほとんどのプロジェクトにはコードをテストするテストスイートがありますが、さらにテストを追加できる箇所は常に存在します。  
Cならgcov、PerlならDevel::Coverなどのカバレッジツールを使って、テストスイートでカバーされていない箇所を特定し、テストを追加します。

9. **コンパイラ警告を消す**: 多くのCベースのプロジェクトでは、ビルド時に奇妙なコンパイラ警告が表示されます。  
これらの警告は通常問題の兆候ではありませんが、そう見えることがあります。。  
警告が多すぎると、コンパイラが「狼が来た」と叫んでいるように見えます。  
コードが本当にバグを隠していないか確認し、問題がなければ警告を消す修正を加えることで、誤検知を減らせます。

10. **コメントを追加する**: コードを調べていると、理解しづらい箇所が見つかることがあります。  
もしあなたが混乱したなら、他の人も混乱する可能性が高いです。  
コードにコメントを追加して、パッチとして提出しましょう。

## ドキュメントに取り組む
コードを調べていると、分かりにくい部分を見つけることがあります。
あなたが混乱したなら、他の人も同様に混乱する可能性が高いです。コードにドキュメントを追加し、パッチを提出してください。
ドキュメントとの連携
ドキュメントは、プロジェクトの要素の中でも最も軽視されがちな部分です。
また、プロジェクトに精通した人の視点から書かれたため、初めて触れる人の視点から見た場合、理解しにくい場合があります。
「このマニュアルは、私がすでにパッケージの使い方を理解していることを前提にしているようだ」と感じたことがあるなら、私の言っていることがわかるでしょう。
プロジェクトに深く関わっている人々が気づかないドキュメントの欠点を、新鮮な視点を持つ人が指摘できることがあります。

11. **サンプルを作る**: どのプロジェクトも、使い方の具体例は多いに越したことはありません。  
ウェブAPI、ライブラリ、GUIアプリ（Gimpなど）、コマンドラインツール、いずれでも、適切な使い方の例は長いドキュメントよりもわかりやすく説明できます。  
APIやライブラリなら、ツールを使ったサンプルプログラムを作成します。  
既存のコードから必要最低限に切り出すだけでも構いません。  
ツールなら、日常生活でどのように使っているかを実例として示します。  
視覚的に理解したい場合は、重要なプロセス（アプリのインストール手順など）のスクリーンキャプチャも有効です。

## コミュニティに取り組む

オープンソースはコードだけでなく、コミュニティがあって初めて機能します。  
コミュニティを育てる方法はいくつもあります。

12. **質問に答える**: コミュニティを育てる最良の方法は、他の人を助けることです。  
特に初めての人の質問に答えることは、プロジェクトの成長と活性化に重要です。  
初心者を助ける時間は、将来的に活発なコミュニティメンバーを生む投資です。  
誰もがどこかから始める必要があり、プロジェクトは常に新しい人材の流入を必要としています。

13. **ブログ記事を書く**: 自分のブログがあるなら、プロジェクトの使用体験について書きましょう。  
ソフトウェア使用中に直面した問題とその解決方法について書きます。  
これにより、他の人にもプロジェクトを意識させ、同じ問題に直面した人が将来検索した際に役立つ情報を提供できます。  
（技術的冒険のブログは、次に仕事で同じソフトウェアを使うときの実務経験を示すのにも役立ちます）

14. **ウェブサイトを改善する**: ウェブデザインのスキルがある場合、プロジェクトのウェブサイトや公開イメージの改善に貢献できます。  
プロジェクトのグラフィックを刷新したり、ロゴを作成したりすることも価値があります。  
コミュニティ内でこうしたスキルを持つ人は少ないことが多く、非常に歓迎されます。

15. **技術ドキュメントを書く**: アプリケーションやソフトウェアの動作について書けるなら、技術ドキュメントを作成できます。  
特にオープンソースで、一般向けに更新・拡張・作成が必要なドキュメントに最適です。  
平易な英語で書けば書くほど良いです。プログラマーでなくても技術ドキュメントは書けます。

最も重要なのは、周囲の人々が何を話しているかに耳を傾けることです。  
差し迫ったニーズに気づけるかどうかを探してみましょう。  

例えば、最近Parrotの開発者向けメールリストでは、古いTracシステムを廃止して、GitHubをトラブルチケット管理システムとして使用することが決まりました。  
一部の人は反対でした。というのも、既存のチケットをGitHubに移行する方法がなかったからです。  
1日の議論のやり取りの後、私は「コンバータを作ってみたらどうですか？」と提案しました。  
人々はそのアイデアに大喜び。私は450件以上のチケットを変換するプログラムを作成し、チケット履歴を一切失うことなく移行に成功しました。  
これは大きな成功でした。私も貢献でき、コア開発者たちはParrotの開発業務に集中できたのです。

16. **教え、他者を助ける**:  
あるトピックについてより深く学ぶ最良の方法は、それを教えてみることです。  
最高の教師は、複雑なことをシンプルな例で説明できる人です。  
そのため、最高の学習者であり、プログラミングの世界で最高であるためには、まず最高の教師になろうとする必要があります。  
他者に教えることで、自分自身の理解も深まり、スキルや知識も向上します。  
誰かから助けを得たとき、それを自分だけに留めず、他の人と共有してください。  
そうすることで、世界はより良い場所になります。