走向 MOTU/开发者道路的最大障碍是什么？
- maco
9
7请将MOTU设为一个链接，指向https://wiki.ubuntu.com/MOTU，以便那些不了解它的人（比如我）可以点击查看。 - Steve Armstrong
1我同意提供一个链接会很有帮助。然而，考虑到这个问题是关于为什么人们不参与某个特定事物的原因，最好还是在问题中解释一下行话的含义。 - moberley
@moberley：MOTU 是指能够将软件包上传到 Ubuntu 存档的 universe（宇宙）和 multiverse（多元宇宙）部分的开发人员。 - txwikinger
忘记续订我的ubuntu-dev和ubuntu-coredev会员资格，又没有时间重新进行申请流程，这就是为什么我不再是MOTU/coredev的原因;-) - raphink
@Raphink: 我非常肯定，要取消过期状态，你只需要给 DMB 发电子邮件并请求重新加入即可。我相信这就是 Daniel Chen 恢复核心开发者权限的方式。 - maco
我要求恢复ubuntu-members会员资格，这样我的@ubuntu.com邮箱就能再次正常工作了。这已经不太容易了，所以我对ubuntu-dev和ubuntu-coredev并不确定，尤其是因为已经过了相当长的时间。 - raphink
其实，有趣的是我已经不再是 MOTU 了，但我仍然是 LP 上 REVU-admins 的所有者 :-) - raphink
1由于问题的风格，转为社区维基。 - Marco Ceppi
我认为最大的障碍是你实际上不能在灰骷髅城堡里闲逛。 - intuited
11个回答
我认为最大的技术障碍是知道如何创建Debian软件包。尽管创建一个可工作的软件包相对简单，但要创建符合Debian和Ubuntu标准的软件包就要困难得多。此外，关于如何创建软件包的指南通常处理的是在你有需要编译的源代码的情况下。这对于用解释型语言编写的应用程序来说可能会让人感到困惑。
最大的社交障碍可能是知道如何将软件包上传到宇宙/多元宇宙存储库中。更简单的方法是创建自己的ppa并将软件包上传到那里。
最大的社交障碍可能是知道如何将软件包上传到宇宙/多元宇宙存储库中。更简单的方法是创建自己的ppa并将软件包上传到那里。
- dv3500ea
现在，人们喜欢通过驾车进行贡献。
20年前，如果你有一个宠物项目，你通常会把很多精力集中在上面。今天，你每天访问数十个网页，有很多社交网络或其他社区，你可以为维基、论坛和其他东西做出贡献。虽然这导致更多的人做出了贡献，但也导致人们期望低门槛的入口（比如“只需点击网站即可编辑它”）。否则，他们可能会转向其他社区。
因此，您应该寻找 MOTU 过程中的障碍。我记得 GroundControl 项目降低了在 launchpad 托管项目中进行补丁贡献的门槛。也许您需要类似的新工具，这样新的 MOTU 候选人就不必费力地学习大量的命令行工具。虽然这些当前的工具可能很强大，但正确使用它们可能需要很多精力。
- Bananeweizen
5
3我不确定我是否喜欢那些不会使用Shell的人来维护软件包的想法，因为Shell脚本是打包的重要组成部分（也就是说，你需要编写/修改许多软件包的Shell脚本才能使其正常工作）。 - maco
@maco：你想要吸引新的贡献者吗？如果是的话，你应该接受流程可能需要改变（不仅仅是参与其中的人）。精英主义的思维方式会排除掉潜在社区的很大一部分。而且，如果你想要启动一个分布式的努力，命令行通常是一个非常糟糕的工具来支持这一点。 - Bananeweizen
1这就像说“你需要了解一些C语言才能编写内核补丁”是精英主义的观点。事实上，你只需要知道如何使用命令行来编写打包脚本。即使有一个图形界面用于制作软件包，最终也会出现一堆“在此处键入postinst shell脚本”的文本框。 - maco
1我的评论并不是关于技术上的必要性。我会试着重新表达一下（我不是以英语为母语）：首先你要求增加贡献者。然后我在你的评论中读到：如果你不会写shell脚本，那么你就太笨了，不能参与打包工作。这让我很不爽。我仍然认为你的假设是错误的。在Ground Control之前，每个人都必须了解版本控制系统才能修补LP中的某个项目。而GC则专注于修补这个单一用例，并消除了对版本控制系统的了解需求，而不是让版本控制变得更容易。 - Bananeweizen
1我并没有在任何地方说“愚蠢”。我说这是一项必要的技能。对于任何稍微复杂的软件包，你将不得不编写一个Shell脚本。无知（还没有学会某种技能）和智力绝不是一样的东西。 - maco
提供更好的文档。
我已经参加了两次与封装和MOTU相关的开发者周IRC会议，并发现在这些会议中，你通常对过程有一个模糊的理解。但是如果你在两周后再看Ubuntu维基页面，你就无法把所有的内容连接在一起了。这些页面通常是一些已经详细了解过程的人列出的要点清单。但这对新手来说还不足以使内容易于理解。
所以也许你应该尝试使文档维基页面更详细地解释过程、工具和涉及的人员。甚至可以提供完整的示例。在IRC会议期间总是有可重复的示例，也许这些示例与维基页面之间能产生差异。
我已经参加了两次与封装和MOTU相关的开发者周IRC会议，并发现在这些会议中，你通常对过程有一个模糊的理解。但是如果你在两周后再看Ubuntu维基页面，你就无法把所有的内容连接在一起了。这些页面通常是一些已经详细了解过程的人列出的要点清单。但这对新手来说还不足以使内容易于理解。
所以也许你应该尝试使文档维基页面更详细地解释过程、工具和涉及的人员。甚至可以提供完整的示例。在IRC会议期间总是有可重复的示例，也许这些示例与维基页面之间能产生差异。
- Bananeweizen
1
2我同意维基页面并不是很有帮助。当我刚开始的时候，我发现Daniel Holbach在YouTube上的视频最有帮助。IRC会话的日志是否发布在维基上？ - maco
我发现最大的障碍是Ubuntu开发者页面：http://www.ubuntu.com/community/get-involved/developers
很多次，我都充满热情地决定为Ubuntu贡献至少一个补丁...于是我去网站上最自然的地方...结果却在一片文档的海洋中迷失了方向。几个小时过去了，我仍然不知道应该为什么写一个补丁。当我浏览Ubuntu的错误报告时，经常会找到补丁...其中有许多只是闲置不用。
至于软件包，我试图弄清楚如何制作它们，但真的很困惑。我还尝试参与Launch Pad，但界面比Source Forge复杂得多，我无法将自己的代码放到LP上。对于新用户来说，这非常困难。
- Greg
1
2是的，Launchpad设计存在问题。在LP上事情并不明显。虽然很简单，但你必须费很大劲才能找到它。新用户很容易迷失方向。它需要重新设计，使其更加明显和简单，就像GitHub一样。 - Owais Lone
成为MOTU是一种责任。
嗯，显然，第一原因是不够技术知识，第二原因是有太多其他事情要做。但在你的目标受众中，我认为主要原因是这是一种责任。
如果我为自己编译一个软件包，没人会在乎我是否遵守了技术和法律政策。没人会指望我打包一个更新版。没人会要求我修复错误。
如果我将我的软件包上传到ppa，可能会有一些人在意。但期望值没有那么高。我可以消失不见，让人们在他们的博客上抱怨说可悲的是这个软件包在natty narwhal上不可用。
如果我成为MOTU，突然间我有了一项重大责任。用户会带着错误报告来找我，如果我昨天没解决好他们会抱怨。用户会期望我在新版本上游可用后立即上传软件包。我必须向非技术用户解释他们做错了什么。与在论坛上发帖不同，我不能忽视我不想回答的问题。而其他开发者可能会追究我，因为我弄砸了某个东西——这可能让人感到害怕。
那我能得到什么？
有一种模糊的感觉，我帮助了别人。这是很重要的。但如果这是我的主要动机，那么打包软件如何与在救济厨房帮忙或辅导失业移民邻居的孩子相比呢？
简历上的一个项目？嗯，作为程序员参与自由开源软件项目会更受赞赏。（这可以让你获得项目管理和长期维护等难以在大学课程中教授的经验。）事实上，成为DD/MOTU对于那些不喜欢政治参与的雇主来说可能会引起怀疑（你公开支持自由开源软件，这意味着你在政治上表达了支持）。
满足感？远不及从零开始编写自己的程序。编程比打包更具创造性。其中有一种巨大的成就感。有值得夸耀的权利。但是打包呢？那只是一项琐事。它并不光彩。
（上面是第三人称的“我”。我认为我给出的理由适用于大多数人，但程度不同。对我个人来说，主要是有太多其他事情要做，而且打包缺乏创造性成就感。）
（出于好奇，Ubuntu是否缺乏人手？）
嗯，显然，第一原因是不够技术知识，第二原因是有太多其他事情要做。但在你的目标受众中，我认为主要原因是这是一种责任。
如果我为自己编译一个软件包，没人会在乎我是否遵守了技术和法律政策。没人会指望我打包一个更新版。没人会要求我修复错误。
如果我将我的软件包上传到ppa，可能会有一些人在意。但期望值没有那么高。我可以消失不见，让人们在他们的博客上抱怨说可悲的是这个软件包在natty narwhal上不可用。
如果我成为MOTU，突然间我有了一项重大责任。用户会带着错误报告来找我，如果我昨天没解决好他们会抱怨。用户会期望我在新版本上游可用后立即上传软件包。我必须向非技术用户解释他们做错了什么。与在论坛上发帖不同，我不能忽视我不想回答的问题。而其他开发者可能会追究我，因为我弄砸了某个东西——这可能让人感到害怕。
那我能得到什么？
有一种模糊的感觉，我帮助了别人。这是很重要的。但如果这是我的主要动机，那么打包软件如何与在救济厨房帮忙或辅导失业移民邻居的孩子相比呢？
简历上的一个项目？嗯，作为程序员参与自由开源软件项目会更受赞赏。（这可以让你获得项目管理和长期维护等难以在大学课程中教授的经验。）事实上，成为DD/MOTU对于那些不喜欢政治参与的雇主来说可能会引起怀疑（你公开支持自由开源软件，这意味着你在政治上表达了支持）。
满足感？远不及从零开始编写自己的程序。编程比打包更具创造性。其中有一种巨大的成就感。有值得夸耀的权利。但是打包呢？那只是一项琐事。它并不光彩。
（上面是第三人称的“我”。我认为我给出的理由适用于大多数人，但程度不同。对我个人来说，主要是有太多其他事情要做，而且打包缺乏创造性成就感。）
（出于好奇，Ubuntu是否缺乏人手？）
- Gilles 'SO- stop being evil'
4
1是的，有。你见过我们的漏洞追踪器吗？ - maco
@maco：在MOTU页面上，我很容易了解到什么是MOTU以及如何成为其中之一。但是我没有看到关于“Ubuntu大叔需要你！”的任何信息。我认为Bug跟踪器对于普通用户来说并没有太多帮助；例如，许多未关闭的bug可能意味着有很多报告后就离开的用户，并没有提供足够的信息来重现这些bug。 - Gilles 'SO- stop being evil'
我必须完全同意Gilles的观点。如果我有更多时间投入到开源项目中，我有几个我很想编程的项目。 - Javier Rivera
有很多这样的错误，但由于不活跃而会最终关闭。在Launchpad上有大约2000个带有补丁的错误报告。Operation Cleansweep的目标是回顾这些补丁，并将好的补丁发送到上游，坏的则予以拒绝。如果这些补丁好并且不能等待整个发布周期才进入上游版本，它们需要被打包。尽管有许多补丁已经存在多年，我们还没有跟上它们提交的速度。 - maco
“语言”是我的主要问题，因为我对英语还没有足够的自信，因此我不能轻松地理解其他开发人员试图告诉我的内容。
- chilicuil
我认为这有几个原因。我也认为这些原因通常是个体的。
其中一个问题是整个MOTU系统的变化。我相信，这些变化可能会让人感到困惑，并且更多地以技术为导向实施，不幸的是并没有完全得到社区的支持（也许只是因为它令人困惑）。
我还认为，在某些情况下，成为MOTU的动机可能不够明确。在我看来，成为MOTU是一种责任，而不是特权。这与头衔无关，而是与通过该头衔获得的访问权限帮助Ubuntu社区的能力有关。因此，整个批准过程可能需要进行修改（或延长）。MOTU通常自荐，然后委员会会审查他们是否准备好成为MOTU。也许应该允许同行认为某人已经准备好成为MOTU的人提名。这将更加准确地反映出提名是为了帮助流程，而不是为了获得头衔。我理解，将其作为唯一方式也存在问题，因此，我更愿意将其视为一种选择而不是唯一的方式。
其中一个问题是整个MOTU系统的变化。我相信，这些变化可能会让人感到困惑，并且更多地以技术为导向实施，不幸的是并没有完全得到社区的支持（也许只是因为它令人困惑）。
我还认为，在某些情况下，成为MOTU的动机可能不够明确。在我看来，成为MOTU是一种责任，而不是特权。这与头衔无关，而是与通过该头衔获得的访问权限帮助Ubuntu社区的能力有关。因此，整个批准过程可能需要进行修改（或延长）。MOTU通常自荐，然后委员会会审查他们是否准备好成为MOTU。也许应该允许同行认为某人已经准备好成为MOTU的人提名。这将更加准确地反映出提名是为了帮助流程，而不是为了获得头衔。我理解，将其作为唯一方式也存在问题，因此，我更愿意将其视为一种选择而不是唯一的方式。
我也知道过去有一些关于人们更关注KDE的问题。希望这些问题已经得到解决，但如果这一点能够更广泛地为人所知，那会很好。
显然，这些只是我注意到的几个问题。每个人都不同，会看到不同的事物，或者受到同样事物的不同影响。因此，这些问题可能无法阻止所有人，也不是导致这个问题的唯一原因。
- txwikinger
5
赞助商应该告诉他们赞助的项目参与者，当他们认为准备好了时，"嘿，也许你现在应该申请一下"，但我不知道这种情况有多常见。我曾建议一个我指导的人申请，但他改变了发展方向，转而关注其他领域。 - maco
当一个赞助商告诉某人去申请，或者这个人是由赞助商提名的时候，仍然存在着一些差别。 - txwikinger
啊？赞助商不能提名人，赞助商倡导被赞助者自我提名。 - lfaraone
txwikinger建议赞助商应该能够提名人选。这种情况已经发生过一次。有些人为Sarah Hobbs创建了一个维基页面，并通过电子邮件向TB发送了推荐信，因此当有明确的支持声音时，她出现在IRC会议上迈出了最后一步。 - maco
2@Ifaraone：我建议一些好人可能不会自荐，因此我们会失去他们。最终，一个优秀的人成为MOTU对Ubuntu来说是一种胜利，也许我们应该考虑这个问题。 - txwikinger
什么阻止我成为 MOTU？
尽管 Ubuntu 社区非常友好（我还没有因为新手问题而被人嘲笑），但我认为关于打包过程的文档很少且不完整（甚至 Debian 的新维护者指南中也有很多“这个主题超出了本文档的范围”的内容）。如果考虑到英语不是母语的人（比如我），这个过程就更加困难和混乱。
如果有一份简单明了的文档，所有事情都会变得更容易，但是那些有技术能力撰写文档的人太忙了，无法完成这项工作。
尽管 Ubuntu 社区非常友好（我还没有因为新手问题而被人嘲笑），但我认为关于打包过程的文档很少且不完整（甚至 Debian 的新维护者指南中也有很多“这个主题超出了本文档的范围”的内容）。如果考虑到英语不是母语的人（比如我），这个过程就更加困难和混乱。
如果有一份简单明了的文档，所有事情都会变得更容易，但是那些有技术能力撰写文档的人太忙了，无法完成这项工作。
- josernestodavila
我在这里发布了一些想法：http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/
有一件事我真的想说的是，我想知道有多少开发者不使用可以轻松插入打包工具的构建系统。我正在进行Python开发。我的世界围绕着setuptools和distribute展开，是的，我可以将用这些构建的东西导出，但是为了什么呢？我已经有一个可分发的东西了。我想知道脚本语言的兴起是否导致了对使用Debian打包工具以及MOTU级别的组装事物缺乏经验和渴望。
- Rick
对我来说，可能与时间有关。目前我没有太多时间去投入。 起初我开始进行错误分类，但很快发现事情有些复杂。你真的需要深入研究。
然后是错误修复，我知道我会喜欢那个。阻止我帮助这方面的原因是你需要运行一个开发分支或其他什么东西。我曾经试图在系统监视器中解决一个小问题（https://bugzilla.gnome.org/show_bug.cgi?id=611738） 所以我开始使用Ground Control获取所需的源代码并修复错误。然而，由于依赖关系，事情并不那么容易。我知道我应该只在开发版本上工作，并测试它是否已在那里修复。然而，为了尝试这一点，我需要下载许多其他GNOME软件包的源代码。这在groundcontrol上并不容易。而且最好在工作机器上完成。所以我就到此为止了。（再次说一遍，这需要我花费太多时间，仅仅是为了开始）
关于包装，我对需要包装的任何东西都不了解。我曾经做过一个关于包装的教程，发现对于小型应用程序来说并不太困难。然而，我从未去寻找需要包装的物品清单，因为我知道可能会有这样的清单... :)所以对我来说基本上只是时间问题，我想帮忙，但每隔一段时间我只有几个小时（大约2个小时）左右的时间。在那么短的时间内，我似乎无法开始进行这项工作。
- WLigtenberg
1
你不需要依赖源码，只需要常规的deb包。为什么不设置一个开发版本的虚拟机来工作呢？这样你就不必搞乱你的环境了（尽管我从2007年2月开始几乎持续运行开发版本...比我开始做与打包/修复Ubuntu错误相关的事情还早一年）。一周修复一个bug在2小时内绝对是可能的，一旦你设置好了你的环境。至于要打包的事物清单：在Launchpad上有一个"needs-packaging"标签。打包现有的补丁也非常有用！ - maco