问题描述
对于不是MOTU(维护Universe和Multiverse软件repositories的人)并且没有“我将在$ date之前申请MOTU”计划的人：
是什么使您和其他与您一样的人无法成为MOTU？是什么让您认为自己无法成为一体？
我指的是社会和技术障碍。
编辑：我只是说MOTU，因为它是一个相当普通的组，但是“为什么不打包/打补丁并打算最终尝试上载权限？”是一个更通用的版本。
最佳解决思路
提供更好的文档。
我参加了与包装和MOTU内容有关的开发人员周IRC研讨会(已经两次)，发现在这些会议期间，您通常对过程有模糊的了解。但是，如果两周后再查看Ubuntu Wiki页面，您将无法再将所有内容整合在一起。这些页面通常是一些已经很详细地了解该过程的人的要点列表。但这还不足以使新手可以理解这些内容。
因此，也许您应该尝试使文档Wiki页面更详细地解释过程，工具和相关人员。甚至带有完整的示例。在IRC会话期间，总是有可重复的示例，也许这些示例对Wiki页面有所帮助。
次佳解决思路
我认为最大的技术障碍是知道如何创建Debian软件包。尽管创建工作包相对简单，但要创建符合Debian和Ubuntu标准的软件包却要困难得多。另外，有关如何创建软件包的指南通常会处理您具有需要编译的源代码的情况。这对于使用解释语言编写的应用程序可能会造成混淆。
最大的社会障碍可能是知道如何将软件包上载到Universe /Multiverse存储库中。只需创建自己的ppa并在那里上传软件包，就容易得多。
第三种解决思路
如今，人们喜欢drive-by的贡献。
20年前，如果有宠物项目，通常会把大量精力投入到宠物项目上。今天，您每天访问数十个Internet页面，并且有很多社交网络或其他社区，您可以在其中贡献Wiki，论坛和其他内容。虽然这导致更多的人做出了贡献，但也导致人们期望进入的门槛较低(请直接单击网站进行编辑)，否则他们可能会转向其他社区。
因此，您应该在MOTU过程中寻找障碍。我记得GroundControl项目可以降低启动板托管项目中补丁贡献的障碍。也许您需要类似的新工具，所以新的MOTU候选人不必摆弄许多命令行工具。虽然这些当前的工具可能功能强大，但可能需要大量的精力来学习如何正确使用它们。
第四种思路
我发现的最大障碍是Ubuntu开发人员页面：http://www.ubuntu.com/community/get-involved/developers
如此多次，我已经决心要为Ubuntu贡献至少一个补丁……所以我去了网站上的自然位置……最终迷失于大量文档中。几个小时后，我仍然不知道该写些什么补丁。当我查看Ubuntu的bug时，我经常会找到补丁……许多只是闲置着的补丁。
就包装而言，我试图弄清楚如何制作它们，这确实令人困惑。我也尝试参与启动板，但是界面比Source Forge复杂得多，我无法在LP上获得自己的代码。对于新用户而言，这非常困难。
第五种思路
成为MOTU是一种责任。
好吧，显然，第一个原因是技术上知识不足，第二个原因是您宁愿做很多事情。但是，在您的目标受众中，我认为主要原因是这是一种责任。
如果我为自己编译一个程序包，则没有人会在乎我是否遵守技术和法律政策。没有人会期望我打包一个更新的版本。没有人会要求我修复错误。
如果我将包裹上传到PPA，可能会有几个人在乎。但是期望并不高。我只是消失了，让人们在他们的博客上抱怨该软件包无法用于natty narwhal，这是多么可悲。
如果我成为MOTU，突然之间我将承担重大责任。用户会来找我报告错误，如果我昨天没解决，会抱怨。用户将期望我在上游提供该软件包的新版本。我将不得不向非技术用户解释如何弄清楚他们做错了什么。与在论坛上发帖不同，我不应该忽略我不想回答的问题。其他开发人员可能会追随我，因为我搞砸了某些东西–这可能令人生畏。
我能得到什么呢？
-
我帮助别人的模糊感。那很重要。但是，如果这是我的主要动机，那么包装软件如何与在煮汤厨房中帮忙或为您的out-of-work移民邻居的孩子提供辅导相提并论？
-
我简历上的要点？嗯，以程序员的身份参加FOSS会受到更多的赞赏。 (它为您提供了项目管理和long-term保养等方面的经验，这些东西在大学课程中很难教到。)实际上，对于许多对politically-involved员工不满的雇主，担任DD /MOTU似乎很可疑(您正在公开地提供政治支持。到FOSS)。
-
有满足感吗？比起从头开始编写自己的程序要少得多。编程比打包更具创造力。有很大的成就感。吹牛的权利。但是在包装上？这很麻烦。这不是迷人的。
(这是上面的third-person “I”。我认为我给出的原因适用于大多数人，但程度有所不同。就我个人而言，我主要希望这样做，而包装缺乏创造力。)
(出于好奇，Ubuntu是否缺乏人力？)
第六种思路
语言，我的主要问题是我对英语仍然不够自信，因此，我不容易理解其他开发人员试图告诉我什么
第七种思路
是什么阻止我成为MOTU？
尽管Ubuntu是一个非常不错的社区(但尚未引起n00bie问题的困扰)，但我认为关于打包过程的文档很少/不完整(即使Debian的New Maintenanceer指南也充斥着“该主题不在讨论范围内”)文档”行)。如果您考虑到这一事实，并考虑母语不是英语的人(例如我)，那么这个过程将更加困难和顺心。
通过简单，正确的方法来编写文档，对我们所有人来说，所有事情都将变得更加容易，但是拥有技术娴熟的技能来编写该文档的人都忙于这样做。
第八种思路
我认为有几个原因。我也认为原因通常是个人原因。
目前的问题之一是整个MOTU系统的变化。我相信，这些更改可能会造成混淆，并且已在技术路线上进行了更多实施，但不幸的是，这些更改并未使社区充分参与(也许只是因为它令人困惑)。
我还认为，在某些情况下，成为MOTU的动机并不尽如人意。恕我直言，成为MOTU是责任，而不是特权。它与标题无关，而是与它附带的访问权限有关帮助Ubuntu社区的能力。因此，有可能整个审批流程都可以修改(或扩展)。 MOTU通常会提名自己，然后董事会会检查他们是否准备好成为MOTU。也许有可能，相信某人已准备好成为MOTU的同龄人能够提名该人。恕我直言，这更代表了这样一个事实，即提名是为了帮助过程，而不是获得头衔。我知道，仅此一种方法也有其问题，因此，我宁愿将其视为替代方法，也是唯一的方法。
我还知道过去人们会更加关注KDE时会遇到一些问题。希望已解决了这些问题，但如果将其广为人知也许会很好。
显然，这些只是我注意到的几个问题。人们是不同的，会看到不同的事物，或者受同一事物的影响不同。因此，这些问题可能不会阻止所有人，也不是导致此问题的唯一原因。
第九种思路
我在这里发表了一些想法：http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/
我真正想带出的一件事是，我想知道有多少开发人员没有使用轻松插入打包工具的构建系统。我正在做python开发。我的工作集中在setuptools上并进行分发，是的，我可以使用我用这些工具构建的东西并将其导出，但是目的是什么？我已经有一些可分配的东西。我想知道使用自己的构建工具/分发方法的脚本语言的兴起是否会导致缺乏经验和渴望，无法将这些东西与debian打包工具以及MOTU级别放在一起。
第十种思路
对我来说，这可能与时间有关。目前，我没有很多时间可以投资。我从错误分类开始，但是很快发现事情要复杂一些。而且，您确实需要全神贯注。
然后是错误修复，我知道我会喜欢的。使我无法提供帮助的是，您需要运行开发部门或其他事务。我曾经开始在System Monitor(https://bugzilla.gnome.org/show_bug.cgi?id=611738)中研究我的剪纸，所以我开始使用Ground Control来获取所需的源并进入那里修复错误。但是，由于依赖关系，事实并非如此简单。我知道我应该只在开发版本上工作，并测试该版本是否已修复。但是，只是为了尝试我需要下载许多其他gnome软件包的源代码。地面控制并不容易。您可能应该在工作机器上执行此操作。所以我停在那里。 (再次，这会花我太多时间，只是为了开始)
关于包装，我只是不知道需要包装的任何东西。我曾经做过关于包装的教程，发现对于小型应用程序来说并不太困难。但是从来没有出去寻找需要包装的东西的清单，因为我知道可能有一个… 🙂
所以基本上对我来说只是时间，我想帮忙，但每隔一周左右我就有几个小时(2个左右)。在这么短的时间内，我似乎无法开始。