走MOTU /开发者路径的最大障碍是什么？
对于那些不是MOTU （维护Universe和Multiverse软件存储库的人 ）并且没有“我将按照$ date申请MOTU”的计划而言：
是什么让你和你这样的人试图成为MOTU？ 是什么让你认为你不能成为一个？
我指的是社会和技术障碍。
编辑：我只是说MOTU，因为它是一个非常通用的组，但“你为什么不打包/修补并打算最终尝试上传权限？” 是一个更通用的版本。
提供更好的文档。
我参加了与包装和MOTU材料相关的开发者周IRC会议（已经两次），并发现在这些会议期间，您通常对该过程有一个模糊的理解。 但是如果你在两周后查看Ubuntu wiki页面，就不能再将所有部分拼凑在一起了。 这些页面通常是那些已经详细了解该过程的人的子弹点列表。 但这还不足以使新手可以理解这些内容。
所以也许你应该尝试让文档维基页面更详细地解释涉及的过程，工具和人员。 或者甚至是完整的例子。 在IRC会议期间，总会有可重复的示例，也许这些示例会对维基页面产生影响。
我认为最大的技术障碍是知道如何创建Debian软件包。 虽然创建一个工作包相对简单，但创建符合Debian和Ubuntu标准的包更加困难。 此外，有关如何创建包的指南通常会处理您需要编译源代码的情况。 对于用解释语言编写的应用程序，这可能会令人困惑。
最大的社交障碍可能是知道如何将包上传到Universe / multiverse存储库中。 只需创建自己的ppa并在那里上传包就简单多了。
如今人们喜欢驾车的贡献 。
20年前，如果你有一个宠物项目，你通常会把很多精力集中在宠物项目上。 今天，您每天访问数十个互联网页面，并且有许多社交网络或其他社区，您可以在其中贡献维基，论坛和其他内容。 虽然这导致了更多人的贡献，但它也导致人们期待低障碍条目（只需点击网站进行编辑）。否则他们可能会转向其他社区。
因此，您应该在MOTU过程中寻找障碍。 我记得GroundControl项目降低了启动板托管项目中补丁贡献的障碍。 也许您需要类似的新工具，因此新的MOTU候选人不必使用大量的命令行工具。 虽然这些当前的工具可能很强大，但学习如何正确使用它们可能需要很多精力。
我发现的最大障碍是Ubuntu开发者页面： http ： //www.ubuntu.com/community/get-involved/developers
很多次，我已经热情地决定为Ubuntu贡献至少一个补丁…所以我去了网站上的自然地方……最终迷失在文档的海洋中。 几个小时后，我仍然不知道我应该写一个补丁。 当我查看Ubuntu漏洞时，我经常会找到补丁……许多人只是闲置在那里。
就包裹而言，我试图弄清楚如何制作它们，这真的令人困惑。 我也试图参与Launch Pad，但界面比Source Forge复杂得多，我无法在LP上获得自己的代码。 这对新用户来说非常困难。
成为MOTU是一项责任 。
好吧，显然，＃1的原因在技术上知识不够，而且＃2的原因是你要做的事情比较多。 但在你的目标受众中，我认为主要原因是它是一种责任。
如果我为自己编制一个包，没有人关心我是否遵循了技术和法律政策。 没有人会来找我，我希望我打包一个更新的版本。 没有人会要求我修复错误。
如果我将我的包裹上传到ppa，一些人可能会关心。 但期望并不高。 我可以消失，让人们在他们的博客上抱怨这个包裹不适用于natty narwhal是多么可悲。
如果我成为MOTU，我突然有了很大的责任。 如果我昨天没有解决问题，用户会来找我错误报告并抱怨。 用户希望我在上游可用时立即上传新版本的软件包。 我必须向非技术用户解释如何弄清楚他们做错了什么。 与在论坛上发帖不同，我不应该忽略我不想回答的问题。 而其他开发者可能会追随我，因为我搞砸了一些东西 – 这可能是令人生畏的。
我有什么收获？
-
一种模糊的感觉，我帮助了人们。 这很重要。 但如果这是我的主要动机，那么包装软件如何与在汤厨房帮助或辅导失业移民邻居的孩子相比？
-
我简历上的一个要点？ 嗯，作为一名程序员参加自由和开放式项目将会更受赞赏。 （它为您提供项目管理和长期维护等在大学课程中难以教授的经验。）事实上，作为一名DD / MOTU看起来对许多对政治参与的员工不满的雇主感到怀疑（你是公开给予FOSS政治支持）。
-
一种满足感？ 比从头编写我自己的程序要少得多。 编程比包装更有创意。 它有很大的成就感。 有吹牛的权利。 但在包装？ 这是一件苦差事。 它并不富有魅力。
（这是上面的第三人称“我”。我认为我给出的理由适用于大多数人，但程度不同。就个人而言，这主要是我宁愿做的事情，包装缺乏创造性成就感。）
（出于好奇，Ubuntu缺乏人力吗？）
语言 ，我的主要问题是我对英语仍然不够自信，因此，我无法轻易理解其他开发者试图告诉我的内容
什么阻止我成为MOTU？
虽然Ubuntu是一个非常好的社区（我还没有因为n00bie问题而受到抨击）但我认为关于打包过程的文档很少/不完整（甚至Debian的新维护者指南都充满了“这个主题超出了范围本文件“行”。 如果你考虑到这个事实，并想到第一语言不是英语的人（比如我），这个过程就更加困难和哥特式。
通过一个简单的，正确的，文档记录，我们所有人都会更容易，但是那些拥有编写文档的技术人员的人太忙了，无法完成。
我认为这有几个原因。 我也认为原因通常是个人的。
目前的一个问题是整个MOTU系统的变化。 我相信，这些变化可能令人困惑，并且已经在技术方面得到了更多的实施，遗憾的是并没有让社区充分参与（可能只是因为它令人困惑）。
我还认为，在某些情况下，成为MOTU的动机并不是那么明确。 恕我直言，作为一个MOTU是一种责任，而不是一种特权。 它不是关于标题，而是关于通过它附带的访问权来帮助Ubuntu社区的能力。 因此，可能会修改（或扩展）整个审批流程。 MOTU通常提名自己，然后董事会看看他们是否准备好成为MOTU。 也许它应该是可能的，那些认为有人准备成为MOTU的同伴能够提名那个人。 这将恕我直言更多的事实，提名是为了帮助这个过程，而不是获得一个头衔。 我明白，以此为唯一方式也存在问题，因此，我宁愿将其视为另一种选择。
我也知道过去一直存在一些问题，人们更关注KDE。 希望这些问题得到解决，但如果这种问题也会广为人知，那也许会很好。
显然，这些只是我注意到的几个问题。 人们是不同的，会看到不同的东西，或者受到不同的影响。 因此，这些问题可能并不能阻止每个人，也不是解决这个问题的唯一原因。
我在这里发布了一些想法： http ： //blog.mitechie.com/2010/08/24/ubuntu-help-wanted/
我真正想要提出的一件事是，我想知道有多少开发人员不使用易于插入打包工具的构建系统。 我在做python开发。 我的世界以设置工具为中心并进行分发，是的，我可以采用我用这些工具构建并将其导出的东西，但到底是什么？ 我已经有了可以分发的东西了。 我想知道脚本语言的兴起是否会使用他们自己的构建工具/分发方法导致缺乏经验和渴望将事物与debian打包工具以及MOTU级别放在一起。
对我而言，这可能与时间有关。 目前我没有太多时间投资。 我开始进行bug分类，但很快发现事情有点复杂。 你真的需要把牙齿塞进去。
然后有bug修复，我知道我会喜欢。 是什么让我无法帮助你，你需要运行一个开发分支或什么的。 我曾经开始使用系统监视器（https://bugzilla.gnome.org/show_bug.cgi?id=611738）处理我的文件。所以我开始使用地面控制，获取所需的源并进入那里修复错误。 然而，由于依赖性，事实certificate并非如此简单。 我知道我应该只处理开发版本，并测试它是否已修复。 但是，只是为了尝试我需要下载许多其他gnome包的源代码。 使用地面控制并不容易。 你可能应该在工作机器上这样做。 所以我在那里停了下来 （再次，这需要我太多时间，只是为了开始这个）
关于包装，我只是不知道任何需要包装的东西。 我曾经做过关于包装的教程，发现它对于小型应用来说并不太难。 然而，从来没有出去寻找需要包装的东西列表，因为我知道可能有一个…… 🙂
所以基本上对我来说只是时间，我想帮忙，但我每隔一个星期左右就会有几个小时（2个或几个小时）。 在那么短的时间内，我似乎无法开始这一点。
当我创建一个包时，它通常会刮伤我的痒，而不是因为其他人想要包。 Checkinstall足以为我制作一个软件包，然后我的痒被刮伤了，我没有个人的动机去额外的距离手动打包它，并弄清楚所有的依赖和东西。
所以我想即使包装易于分发，除了自己包装之外，还有很多工作要做。