MOTU /開発者の道を歩く最大の障壁は何ですか？[閉まっている]

MOTUではない人（UniverseおよびMultiverseソフトウェアリポジトリを維持している人）で、「$ dateまでにMOTUに適用する」という種類の計画がない場合：

あなたやあなたのような他の人がMOTUになろうとしないのはなぜですか？どうしてあなたは自分になれなかったと思いますか？

私は社会的および技術的障壁の両方に言及しています。

編集： MOTUは非常に一般的なグループであるため、MOTUとだけ言っていますが、「パッケージング/パッチを適用して、最終的にアップロード権を試すつもりはないのですか？」さらに一般的なバージョンです。

より良いドキュメントを提供します。

パッケージングとMOTUに関連する開発者向けのIRCセッションに参加しました（既に2回）。これらのセッションでは、通常、プロセスについて漠然と理解していることがわかりました。しかし、2週間後のUbuntu wikiページを見ると、すべての要素をまとめることはできません。これらのページは、多くの場合、すでにプロセスを詳細に理解している人々の一種の箇条書きリストです。しかし、それは初心者が内容を理解できるようにするのに十分ではありません。

したがって、プロセス、ツール、および関係者をより詳細に説明するドキュメントWikiページを取得するようにしてください。または、完全な例もあります。IRCセッション中は常に繰り返し可能な例がありますが、おそらくそれらはWikiページに違いをもたらします。

最大の技術的障壁は、Debianパッケージの作成方法を知ることだと思います。作業用パッケージを作成するのは比較的簡単ですが、DebianおよびUbuntuの標準までのパッケージを作成するのははるかに困難です。また、パッケージの作成方法に関するガイドは、通常、コンパイルが必要なソースコードがある状況を扱っています。これは、インタプリタ言語で書かれたアプリケーションにとって混乱を招く可能性があります。

最大の社会的障壁は、おそらくパッケージをユニバース/マルチバースリポジトリにアップロードする方法を知ることです。独自のPPAを作成し、そこにパッケージをアップロードする方がはるかに簡単です。

最近では、ドライブバイコントリビューションが好まれています。

20年前は、ペットプロジェクトに多くのエネルギーを集中させていました。今日、あなたは1日に何十ものインターネットページにアクセスし、多くのソーシャルネットワークや他のコミュニティがあり、そこでウィキやフォーラムなどに貢献することができます。これにより、より多くの人々が貢献するようになりましたが、低障壁のエントリを期待する人々にもつながりました（「ウェブサイトをクリックして編集するだけ」）。

したがって、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には人材が不足していますか？）

言語、私の主な問題は、私がまだ英語に十分自信がないということです。

何が私をMOTUにするのを止めましたか？

Eventhough Ubuntuは非常に素晴らしいコミュニティです（まだn00bieの質問に火をつけたことがありません）パッケージングプロセスに関するドキュメントはほとんど/不完全であると思います（Debianの新しいメンテナーガイドでさえ「このトピックは範囲外です」このドキュメントの」行）。その事実を理解し、母国語が英語ではない人（私のように）について考えると、プロセスはさらに難しくなります。

シンプルで、要点を言えば、すべてのことを文書化することは私たち全員にとって簡単ですが、その文書を書く技術的なスキルを持っている人は忙しすぎてそれを行うことができません。

これにはいくつかの理由があると思います。また、理由はしばしば個人的なものだと思います。

現時点での問題の1つは、MOTUシステム全体の変更です。変更は混乱を招く可能性があり、技術的なラインでより多く実装されており、残念ながらコミュニティが完全に参加できなかったと考えています（混乱しているからかもしれません）。

また、場合によっては、MOTUになる動機がそれほど明確ではないと思います。私見、MOTUであることは責任であり、特権ではありません。タイトルについてではなく、付属のアクセス権によってUbuntuコミュニティを支援する能力についてです。このため、承認プロセス全体が変更（または拡張）される可能性があります。MOTUは通常自分自身を指名し、ボードはMOTUになる準備ができているかどうかを調べます。おそらく、誰かがMOTUになる準備ができていると信じている仲間がその人を指名できる可能性があります。これは、タイトルを取得するためではなく、プロセスを支援するために指名が行われるという事実をより多く表します。私はこれを唯一の方法にすることにも問題があることを理解しています。したがって、私はむしろそれを唯一の方法であると考えています。

また、過去にKDEに焦点を合わせている人々にいくつかの問題があったことも知っています。これらの問題はうまくいけば対処されていますが、それがもっと広く知られるようになったらいいかもしれません。

明らかに、これらは私が気づいているいくつかの問題にすぎません。人は異なり、異なるものを見るか、同じものによって異なる影響を受けます。したがって、これらの問題はすべての人を止めるわけではなく、この問題の唯一の理由でもありません。

ここにいくつかのアイデアを投稿しました：http : //blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

私が本当に引き出したいのは、パッケージツールに簡単にプラグインできるビルドシステムを使用していない開発者がどれくらいいるのか、ということです。私はpython開発をしています。私の世界はsetuptoolsと配布に集中しており、はい、それらでビルドしたものを取り出してエクスポートすることができますが、どのような目的のためにですか？私はすでに配布可能なものを持っています。独自のビルドツール/配布方法を備えたスクリプト言語の台頭により、debianパッケージツール、つまりMOTUレベルで物事をまとめる経験と欲求が不足するのではないかと思います。

私にとっては、おそらく時間に関係しています。現在、投資する時間はあまりありません。そして、バグのトリアージングから始めましたが、すぐに物事がもう少し複雑であることがわかりました。そして、あなたは本当にその中に歯を沈める必要があります。

それからバグ修正がありますが、それは私が楽しんでいると知っています。私をそこから助けてくれないのは、開発ブランチか何かを実行する必要があるということです。私はかつてシステムモニター（https://bugzilla.gnome.org/show_bug.cgi?id=611738）で私のペーパーカットの作業を開始しました。そこで、必要なソースを取得してそこにアクセスするためにGround Controlの使用を開始しましたバグを修正します。しかし、依存関係のため、それほど簡単ではないことが判明しました。開発バージョンでのみ作業し、そこで修正されるかどうかをテストする必要があることを知っています。ただし、それを試すために、他の多くのgnomeパッケージのソースをダウンロードする必要がありました。これは、地上操作ではそれほど簡単ではありません。そして、おそらくあなたは作業機械でそれをするべきです。だから私はそこで立ち止まった。（繰り返しますが、これを始めるには時間がかかりすぎます）

パッケージングに関しては、パッケージングが必要なことは何も知りません。パッケージングに関するチュートリアルを一度行ったことがありますが、小さなアプリケーションにとってそれほど難しくないことがわかりました。ただし、パッケージが必要なもののリストを探しに出かけたことはありません。

だから基本的に私にとってはそれはただの時間です、私は手伝いたいのですが、私は奇妙な週ごとに数時間（2か何か）しか持っていません。そして、そのわずかな時間で、私はこれを始めることができないようです。

私がパッケージを作成するとき、それは通常、誰かがパッケージを欲しているからではなく、私のかゆみを掻くことです。Checkinstallは私のためにパッケージを作成するのに十分であり、それから私のかゆみはひっかかれます、そして私はそれを手動でパッケージ化するために余分な距離を移動し、すべての依存関係やものを把握する個人的なインセンティブはありません。

ですから、たとえ配布用のパッケージングが簡単であったとしても、それはあなた自身のためのパッケージングを超えたまだまだ多くの仕事だと思います。