MOTU /開発者の道を歩く最大の障壁は何ですか？
より良いドキュメントを提供します。
私はパッケージングとMOTUスタッフに関連する開発者週間IRCセッションに参加しました（すでに2回）。これらのセッション中に、通常、プロセスについて漠然と理解していることがわかりました。しかし、2週間後にUbuntuのwikiページを見ると、すべてのピースをまとめることはできません。これらのページは、多くの場合、すでにプロセスを詳細に理解している人々からの一種の箇条書きリストです。しかし、それは初心者が内容を理解できるようにするのに十分ではありません。
そのため、プロセス、ツール、および関係者を詳細に説明するドキュメントWikiページを取得するようにしてください。または、完全な例もあります。 IRCセッション中は常に繰り返し可能な例がありますが、それらはWikiページに違いをもたらす可能性があります。
最大の技術的障壁は、Debianパッケージの作成方法を知ることだと思います。作業パッケージを作成するのは比較的簡単ですが、DebianおよびUbuntuの標準までのパッケージを作成するのははるかに困難です。また、パッケージの作成方法に関するガイドは、通常、コンパイルが必要なソースコードがある状況を扱っています。これは、インタプリタ言語で書かれたアプリケーションにとって混乱を招く可能性があります。
最大の社会的障壁は、おそらくパッケージをユニバース/マルチバースリポジトリにアップロードする方法を知ることです。独自のPPAを作成し、そこにパッケージをアップロードする方がはるかに簡単です。
最近ではドライブバイの寄付が好きな人。
20年前は、ペットプロジェクトに多くのエネルギーを集中させていました。今日、あなたは1日に何十ものインターネットページにアクセスし、多くのソーシャルネットワークや他のコミュニティがあり、そこでウィキやフォーラムなどに貢献することができます。これにより多くの人が貢献するようになりましたが、バリアの低いエントリを期待する人もいます（「Webサイトをクリックして編集する」など）。
したがって、MOTUプロセスで障壁を探す必要があります。私は、GroundControlプロジェクトを覚えています。これは、ランチパッドがホストするプロジェクトでのパッチの貢献に対する障壁を低くするためです。同様の新しいツールが必要な場合があるため、新しいMOTUの候補者は、多くのコマンドラインツールをいじる必要はありません。それらの現在のツールは強力かもしれませんが、それらを正しく使用する方法を学ぶにはおそらく多くのエネルギーが必要です。
私が見つけた最大の障壁は、Ubuntu開発者ページです http://www.ubuntu.com/community/get-involved/developers
何度も、Ubuntuに少なくとも1つのパッチを提供することに熱心に決心しました...ですから、Webサイトの自然な場所に行きます...そして、ドキュメントの海で迷子になります。数時間後、私はまだ何のためにパッチを書かなければならないのか分かりません。 Ubuntuのバグを調べると、多くの場合、パッチが見つかります。多くのパッチは未使用のままです。
パッケージに関する限り、私はそれらを作る方法を見つけようとしましたが、それは本当に紛らわしいです。 Launch Padにも参加しようとしましたが、インターフェイスはSource Forgeよりもはるかに複雑で、LPで独自のコードを取得できませんでした。新しいユーザーにとっては非常に困難です。
MOTUであることは責任です。
まあ、明らかに＃1の理由は技術的に十分な知識がなく、＃2の理由はあなたがやりたいと思うものが多いことです。しかし、あなたのターゲットオーディエンスの中で、私は主な理由はそれが責任だと思います。
パッケージを自分用にコンパイルする場合、他の誰も私が技術的および法的ポリシーに従っているかどうか気にしません。新しいバージョンをパッケージ化することを期待している人はいません。バグの修正を求められることはありません。
パッケージをPPAにアップロードすると、数人の人が気にするかもしれません。しかし、期待はそれほど高くありません。私はただ消えて、人々が自分のブログで、このパッケージがナッチュイナールには利用できないのがどれほど悲しいかと不平を言うことができます。
私がMOTUになったら、突然大きな責任を負います。ユーザーはバグ報告で私のところに来て、昨日それらを解決しなければ文句を言うでしょう。ユーザーは、アップストリームが利用可能になり次第、新しいバージョンのパッケージをアップロードすることを期待します。技術者でないユーザーに、彼らが何を間違えたかを理解する方法を説明する必要があります。フォーラムに投稿するのとは異なり、私は答えたくないと思う質問を無視することは想定されていません。そして、私が何かを台無しにしたので、他の開発者が私を追いかけるかもしれません。
そして、私は何を得ますか？
私が人々を助けたという曖昧な気持ち。それは重要です。しかし、それが私の主な動機である場合、パッケージングソフトウェアは、スープキッチンを手伝ったり、仕事外の移民の隣人の子供たちを指導したりするのと比べてどうでしょうか。
履歴書の箇条書き？まあ、プログラマーとしてFOSSに参加することはもっと感謝されます。 （大学のコースでは教えるのが難しいプロジェクト管理や長期的なメンテナンスなどの経験ができます。）実際、DD/MOTUであるということは、政治に関わる従業員に眉をひそめる多くの雇用主にとって疑わしいと思われます。 FOSSへの政治的支援を公然と提供しています）。
満足感？自分のプログラムを一から作成するよりもずっと少ないでしょう。プログラミングはパッケージングよりもはるかに創造的です。それには大きな達成感があります。自慢する権利があります。しかし、パッケージングで？面倒です。華やかではありません。
（それは上記の三人称「私」です。私が与える理由はほとんどの人に当てはまりますが、程度はさまざまです。個人的には主に私がやりたいと思う愚かさを持ち、創造的な達成感のないパッケージです。）
（好奇心から、Ubuntuには人材が不足していますか？）
言語、私の主な問題は、私がまだ英語に十分自信がないため、他の開発者が私に伝えようとしていることを簡単に理解できないことです
これにはいくつかの理由があると思います。また、その理由はしばしば個人的なものだと思います。
現時点での問題の1つは、MOTUシステム全体の変更です。変更は混乱を招く可能性があり、技術的なラインでより多く実装されており、残念ながらコミュニティを完全には乗せていませんでした（混乱しているからかもしれません）。
また、場合によっては、MOTUになる動機がそれほど明確ではないと思います。私見、MOTUであることは責任であり、特権ではありません。タイトルについてではなく、付属のアクセス権によってUbuntuコミュニティを支援する能力についてです。このため、承認プロセス全体が変更（または拡張）される可能性があります。 MOTUは通常自分自身を指名し、ボードはMOTUになる準備ができているかどうかを確認します。おそらく、誰かがMOTUになる準備ができていると信じている仲間がその人を指名できる可能性があります。これは、タイトルを取得するのではなく、プロセスを支援するために指名が行われるという事実をより多く表すでしょう。私はこれを唯一の方法にすることにも問題があることを理解しています。したがって、私はむしろそれを唯一の方法であると考えています。
また、過去にKDEに焦点を合わせている人々にいくつかの問題があったことも知っています。これらの問題はうまくいけば対処されていますが、それがもっと広く知られるようになったらいいかもしれません。
明らかに、これらは私が気づいている問題のほんの一部です。人は異なり、異なるものを見るか、同じものによって異なる影響を受けるでしょう。したがって、これらの問題はすべての人を止めるわけではなく、この問題の唯一の理由でもありません。
何が私をMOTUにするのを止めましたか？
Eventhough Ubuntuはとてもいいコミュニティです（まだn00bieの質問に火をつけられたことはありません）パッケージングプロセスについてのドキュメントはほとんど/不完全であると思います（DebianのNew Maintainer Guideでさえ「このトピックは範囲外です」このドキュメントの」行）。その事実を理解し、母国語が英語ではない人（私のように）について考えると、プロセスはさらに難しくなります。
シンプルで、要点を説明すれば、すべてのことを文書化することは私たち全員にとって容易になりますが、その文書を書くための技術的なスキルを持っている人は忙しすぎてそれを行うことができません。
私にとっては、おそらく時間に関係しています。現在、投資する時間はあまりありません。そして、バグの切り分けから始めましたが、すぐに物事がもう少し複雑であることがわかりました。そして、あなたは本当にその中に歯を沈める必要があります。
それからバグ修正がありますが、それは私が楽しんでいると知っています。私をそこから助けられないのは、開発ブランチか何かを実行する必要があるということです。システムモニター（https://bugzilla.gnome.org/show_bug.cgi?id=611738）で私のペーパーカットの作業を始めたので、Ground Controlを使用して、必要なソースを取得してそこにアクセスしましたバグを修正します。しかし、依存関係のため、それほど簡単ではないことが判明しました。開発バージョンでのみ作業し、そこで修正されるかどうかをテストする必要があることを知っています。ただし、それを試すために、他の多くのgnomeパッケージのソースをダウンロードする必要がありました。これは、地上操作ではそれほど簡単ではありません。そして、おそらくあなたは作業機械でそれをするべきです。だから私はそこで立ち止まった。 （繰り返しますが、これを始めるには時間がかかりすぎます）
パッケージングに関しては、パッケージングが必要なことは何も知りません。パッケージングに関するチュートリアルを一度行ったことがありますが、小さなアプリケーションにとってそれほど難しくないことがわかりました。ただし、パッケージが必要なもののリストを探しに出かけたことはありません。
だから基本的に私にとってはただの時間で、私は手伝いたいのですが、奇妙な週ごとに数時間（2時間かそれ以上）しかありません。そして、そのわずかな時間で、私はこれを始めることができないようです。
ここにいくつかのアイデアを投稿しました： http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/
私が本当に引き出したいのは、パッケージツールに簡単にプラグインできるビルドシステムを使用していない開発者がどれくらいいるのか、ということです。 python開発を行っています。私の世界はsetuptoolsと配布に集中しており、はい、それらで構築したものを取り、それをエクスポートできますが、どのような目的のためにですか？私はすでに配布可能なものを持っています。独自のビルドツール/配布方法を備えたスクリプト言語の台頭により、debianパッケージツール、つまりMOTUレベルで物事をまとめる経験と欲求が不足するのではないかと思います。
私がパッケージを作成するとき、他の誰かがパッケージを望んでいるからではなく、通常、私のかゆみを掻くことです。 Checkinstallは私のためにパッケージを作成するのに十分であり、それから私のかゆみはひっかかれます、そして私はそれを手動でパッケージ化するために余分な距離を移動し、すべての依存関係やものを把握する個人的なインセンティブがありません。
ですから、たとえ配布用のパッケージングが簡単であっても、それはあなた自身のパッケージングを超えた多くの仕事だと思います。