FAQ

Inkscapeに貢献したい

どうしたらInkscapeプロジェクトのお手伝いができますか?

開発者であれば、コードを取って来てどこでも好きなところをハックしてください。 そして、結果を他の人と共有したい出来になったらパッチを送ってください。 また、マニュアルやインタフェースのローカライズ （I18N）のためのライターや翻訳者も求められています。

我々は投稿されたものをとても真剣に受け止めており、 「まずパッチ、それから議論」をポリシーとしていますから、 努力してくださった結果が開発コードにすぐに反映される可能性は非常に高いと言えます。 もちろんルールや基準はありますが、 びっくりされるようなものとはならないよう、また明確にするよう心がけています。

コーディング以外にお手伝いする方法はありますか?

もちろんあります。 コーディングしなくてはならない仕事がたくさんあるのはもちろんですが、 プログラミング以外にもプロジェクトに役立つ仕事がたくさんあります。

バグに関する議論と試験

バグを特定して明らかにすることで、 修正に要する時間を大幅に軽減できます。

  • バグを探して報告。コードの品質を保証するために、非常に重要です。
  • 報告されたバグをレビューし、確認。 自分の環境でもバグが発生するか調べ、記述を追加してください。
  • 性能試験。Inkscapeが動作低下するようなSVGを作成し、 試験事例としてバグ追跡に投稿してください。
  • 互換試験。 InkscapeによるSVGのレンダリングを、 BaticやCairoなど他のアプリケーションによるものと比較し、違いがあれば報告してください （両方のプロジェクトに）。
  • バグの優先付け。新しいバグの優先順位は「5」となっています。 内容をチェックし、high/medium/lowの優先度に更新してください。 詳しくはUpdating Tracker Itemsを参照してください。
仲間のユーザの手助け

良いドローソフトを作ることに加え、 我々にとってその回りに良いコミュニティを築くことは非常に重要です。 他のユーザを手助けすることは、このゴールの達成を直接的に手助けしてくれることになります。 何よりも我々は、Inkscapeのコミュニティを気持ちの良い、 礼儀正しい場所にしたいと考えていることを心にとめ、 他の人々との関わりにおいて規範となるような姿勢を心がけてください。

  • チュートリアルの執筆。 まだチュートリアルに書かれていない内容があれば、使い方について記述してください。
  • inkscape-userメーリングリストで応対。 他のユーザから寄せられる質問に答えてあげてください。 そして、Inkscapeの便利な使い方や裏技などの情報を共有してください。
  • クリップアートの作成。openclipart.orgプロジェクトにアップロードできます。
  • Inkscape教室の開催。 身の周りの人にInkscapeの使い方を教えてあげてください。 あるいはイベントやLinuxグループミーティングなどの場で、 Inkscape（や、他のオープンソースなアートツール） を紹介するプレゼンテーションをしてください。
開発（コーディング以外）
  • 翻訳。どのようにしてインタフェースの翻訳をしたら良いかは、 WikiのTranslation informationを参照してください。
  • アイコンやテーマのSVGデザイン。 すでにあるテーマに新しいアイコンを作成したり、新しいテーマを作成したりしてください。 作成したテーマはぜひlibrsvg themesに投稿してください。
  • 新しいダイアログの作成。 ダイアログを改善したり追加したりするアイディアを形にしてください。 UI開発者にとっては、何をしたら良いか把握するのに便利です。
  • パッケージの改善。 どのようにしたらお使いのOS向けのパッケージやLinuxディストリビューションをもっと良いものにできるか、 明らかにしてください。 WikiのCreatingDistsも参照してください。
  • エクステンションの追加。 ファイルのインポート/エクスポートや特殊機能などのために、 Inkscapeは外部プログラムと連係することができます。 外部プログラムを利用するための新しい .inx ファイルを作成してください。 そしてまた、もしPerlやPhytyonなどの言語に詳しければ、 ぜひエクステンションを改良してください。
  • ソースコードのドキュメント追加。 ソースコードには簡単でも良いので説明文が必要です。 関数の説明は、間違いなく次の開発者の役に立ちます。
  • テンプレートの作成。Inkscapeの share/template ディレクトリを参照してください。
  • Wikiの編集。 Wikiは開発情報を得るにはすばらしい場所ですが、 更新したり整理したり、より詳しい説明を加えたりする作業が常に必要です。
  • 将来の開発の計画。Wikiのロードマップを更新したりレビューしてください。 基本的には、開発者と開発しているもの、計画しているもの、 最近開発の終わったものが何であるかについて話、ロードマップを適切に更新してください。
宣伝 - Inkscapeの売り込みと伝道

ユーザ規模の拡大は重要です。 興味を持つユーザが増えれば、 それだけ将来貢献してくれるかもしれない人や褒めてくれる人が増えるということになりますし、 クチコミによるInkscapeの宣伝は重要だと我々は信じています。 すべてのユーザや開発者はInkscapeの親善大使であり、 他の人たちは我々の行いがどれだけ立派かによりInkscapeを判断するでしょう。 我々が礼儀正しく親しみやすい態度を持ち、 Inkscapeが楽しく一緒にやってみたいプロジェクトと思われるようにすることが重要で、 そうすれば伝道も自然とついてくるでしょう。 しかし一般的にコミュニティを築くにあたっては量より質が大事ですから、 行き過ぎた伝道や押し売りは控えてください。 我々は他のアプリケーションと共同して仕事をしていきたいと考えているのであって、 他のソフトウェアをつぶしたいと考えているわけではありませんし、 そうした論評は反生産的です。 我々は期待に応えていく必要があります。 ユーザにはInkscapeでどれほどのことができるかにうれしい驚きを感じてもらいたいと思っていて、 他のプログラムにある機能がないということでがっかりして欲しくありません。 Inkscapeは芸術家に創造的な新しい方法を提供し、 すでにある技術やツールを補完すると考えるべきものです。

  • 記事を書く。オンライン（あるいは印刷版でも）のマガジンやブログに記事を書いてください。 その際は、Inkscapeへのリンクへのリンクをお忘れなく！
  • スクリーンショット。特に新しい機能のもの。
  • 使用例の作成。 使用例は、 いろいろな用途でInkscapeが利用できることを示すのに有効です。 スクリーンショットとテキストを作成し、 Web管理者に（inkscape-develメーリングリスト経由で） 送ってサイトに追加してもらってください。
  • Webサイト関連。Webサイトに関して手伝ってくれるのは、 いつでも歓迎です。 HTML知識は必須で、PHPのノウハウがあればなお結構です。 WebサイトのコードをSubversion (SVN) からチェックアウトしてパッチを送るか、 継続して開発に参加するためにsvnとシェルのアクセスを要求してください。
  • プレゼンテーション。エキスポやシンポジウムなどの大規模行事の場で、 Inkscapeについて話をしてください。 その際、Webサイトでお知らせできるよう、 必ずinkscapeメーリングリストでアナウンスしてください。
  • 開発者のリクルート。 コーディングに興味のある人を探し、Inkscapeの開発に携わるよう勧めてください。
Inkscapeのバナーはどこで入手できますか?

こちらをどうぞ。

http://www.inkscape.org/images/inkscape_80x15.png

Inkscapeの宣伝のためにご自身でバナーやボタンを作成するのは、どうぞご自由に。 優秀な作品には、こちらからリンクします。

どうすればメーリングリストでの炎上を回避できますか?

Inkscapeは親しみやすいコミュニティを維持していることを誇りに思いますが、 それぞれ情熱的で異なる考えを持った人々ですから、 議論が熱くなることもあります。 しかしながら、自分の意見に固執する人がいると、 容易に手に負えない非生産的な口論となり得ますし、 貴重な投稿者をプロジェクトから追い出す羽目にもなりかねません。 ですから、我々はメーリングリストが野蛮なものとならないよう努めることに、 高い優先順位を与えています。

Inkscapeコミュニティでうまくコミュニケーションを図るためのコツはいくつかあります。

  1. 議論をするする際には、とにかく比較をしてはいけません。 本当に優れた機能とは、比較するまでもなく、 ユーザの利用法から見て明らかに優れているものです。 比較をしたからと言って、意見が強化されるわけではありません。 鳴物入りの理屈付けは反発を招くものですから、むしろ弱まってしまいます。 Inkscapeのユーザの多くは、 比較対象となるソフトウェアから逃げるためにInkscapeを使っているのです。

  2. 開発者とユーザと業界の専門家が、 それぞれ完全に別々のグループの人々だと思うのはやめましょう。 開発の熱意は、反対の意味でもあるのです。 開発者は、自分たちの使うソフトウェアを開発しているユーザなのです。 開発者の中には、Inkscapeを日常的に業務に使っている業界の専門家もいます。 このことは、ユーザの平均的な要求や期待に関して始まった議論は、 ユーザが自分の好きなように開発しているという事実との間で、 葛藤が起きる原因にもなっています。

  3. 自分の意見に反対されたからといって、 開発者以外のユーザのニーズや要求が軽視されていると考えるのはやめましょう。 開発者の多くは、 IRCやメーリングリストでユーザの意見を聞き取ることに個人的にたくさんの時間を割いています。 重要な問題であれば、一致した意見が聞かれますからそうとわかります。 ついでながら、私がこれまでに実装してきた機能のほとんどは、 礼儀正しく粘り強い姿勢で要求や必要性を示してきたユーザへの対応としてでした。

    実際、Inkscapeの開発者はユーザ意見の流れにより判断しますから、 自分の意見の正しさを証明するために有効な方法は、 幅広いユーザからの変更要求であることを示したり、 変更が多くのユーザを満足させるものであることを明らかにすることです。 （無知な大衆がいつでも正しいと言うわけではありませんが、 だいたいにおいては強い相関があるものです。）

  4. 名声とはついてくるものであって、要求するものではありません。 これは、コミュニティライフにおける厳しい現実です。 プロジェクトは投稿者に成功してもらいたいものですし、 人々は新しい人が参加してくるのは大歓迎で、手助けするためには最善を尽くします。 あなたが深く関われば関わるほど、血と汗と涙を捧げれば捧げるほど、 コミュニティは応えてくれます。 すばらしいのは、ささいな貢献であっても重要だということです。

    Inkscapeのスローガンは「まずパッチ、それから議論」であることを忘れないでください。 これはただの金言ではありません。 実際に試作して動いているところを見るまで、 議論してもすべての要素を理解できないことが多いのです。 アイデアをパッチという形で提供することは、 他の人がそれを形にするために労力を割かなくてはならないという心配をせずに済むということにもなります。

  5. 我々は全員同じゴールを目指しているのだということを、決して忘れないでください。 何よりもまず、Inkscapeを良いものにして行きたいのです。 議論が熱くなってきたと感じられたら、 そろそろ議論している人たちは合意点を探して、そちらに注意を移すべきです。