我想参与一百幅剪纸项目，但我不知道该做什么。我不是程序员，所以我不确定我是否能做出任何贡献。有人能解释一下“一百张剪纸”项目要做什么吗？
答案1
参与“一百张纸割伤”项目的方法有很多。需要注意的是，您不必是一名程序员就可以做出重大贡献。有很多角色需要填补，编写代码只是修复纸割伤的一小部分。
如果你发现下面有一些你感兴趣的东西，那么加入Launchpad 上的 Paper Cut Ninja 团队，订阅邮件列表，介绍自己，并告诉我们你感兴趣的内容。如果你有任何问题，我们很乐意为你解答。
报告者 - 报告问题
报告问题是每个人都可以做的事情。如果您最喜欢的应用程序中有让您不爽的地方，那就报告它（只要该应用程序包含在桌面上）。如果您真的想参与其中，那么请从桌面上选择一个应用程序，坐下来花一两个小时研究它，看看是否有纸片被剪掉。
分析师——找出真正的问题所在
确认新的错误- 需要有人过来看看新报告的积压错误是否真的是纸上谈兵。坐下来看看有问题的应用程序发生了什么。如果报告没有提供足够的信息，则请求缺少的信息并将报告标记为不完整。
分类已确认的错误- 一旦确认存在错误，就必须有人来找出问题所在。例如，问题出在应用程序本身还是构建应用程序的图形工具包（如 Gtk）上。这通常需要与 Paper Cuts 或 Desktop 团队的某个人交谈，寻求建议，直到您获得足够的经验来自己做出决定。
一旦确定了受影响的软件包，人们就可以找出真正的问题所在。如果您不熟悉软件包本身的代码库，请与软件包开发人员联系以寻求建议。一旦他们告诉您发生了什么，您就应该将该回复作为错误报告的评论发布。
设计师——决定如何应该工作
一旦发现问题，就需要设计修复方案。这不是每个剪纸问题都需要做的（有些剪纸问题只有一种修复方法）。在其他情况下，你应该坐下来，思考如何修复。一旦你有了主意，你应该开始批准你的设计在其实施之前。
开发人员 - 在代码中实现修复
如果你确切地知道发生了什么，那么你就可以直接进入代码并开始修复剪纸问题。你如何进行这项工作取决于你正在开发的应用程序以及该应用程序最初在哪里开发。
如果它是一个 Gnome 应用程序，那么你最好的选择是从git.gnome.org，处理您的补丁并将修复程序导出为.patch文件，您可以将该文件附加到 Gnome Bugzilla 中的错误报告中。
许多其他项目都托管在 Git 存储库中，并在 Bugzilla 中跟踪其问题。如果您甚至不确定该去哪里，那么请进入 #ubuntu-desktop 并询问。那里的某个人会非常乐意为您指明正确的方向。
如果是 Ubuntu 软件包（例如 Unity 或 Ubuntu 软件中心）中的错误，那么有一个很棒的Ubuntu 错误修复指南在 Ubuntu 开发者网站上。
测试人员 - 验证修复是否正常运行
一旦制定了一条路径并提交审批，就需要有人对其进行测试。这可以留给软件包开发人员/维护人员，但他们还有很多其他工作要做，减轻他们在某一领域的工作量意味着他们可以在其他领域做更多的事情。在这方面，如果补丁或分支处于纸上谈兵，无论是在 Launchpad 还是上游，那么在试用之前下载并应用该补丁将大有帮助。
完成测试后，请在上游和 Ubuntu 的错误报告中留下一条消息，详细说明您的结果。一开始，开发人员或维护人员无法简单地相信您说补丁已准备就绪，但如果您经常处理一个软件包，并且开发人员了解您，您的言论将更有分量，您甚至可能被授予上传该软件包源存档的权限。
联络 - 确保修复是上游可接受的
联络员和测试员可以重叠，但不必重叠。一旦确认补丁解决了问题，它需要获得软件包上游开发人员的批准。上游错误跟踪器的评论并不总是发布在 Launchpad 中，因此必须有人充当两者之间的跑者，在两者之间复制和粘贴问题及其答案。请记住，Ubuntu 并不是这些应用程序出现的唯一发行版，开发人员不可能跟踪所有使用其软件的人，因此您必须确保每个处理错误的人员都了解情况。
打包程序 - 将补丁或分支集成到发行版中
编写补丁后，需要将其集成到现有的应用程序包中。这将涉及下载和安装你打算发布补丁的 Ubuntu 版本、下载软件包的源代码、应用补丁并打包结果。Ubuntu 打包指南介绍如何执行此操作。
根据补丁的性质，您可能需要执行最多三次 - 当前稳定版本、当前 LTS 和当前开发版本都是补丁的可行目标。
更新程序 - 处理 SRU 以将补丁纳入稳定版本
这不是每个人都能做到的，因为它需要上传到 Ubuntu 软件包档案库的权限。一旦补丁被打包，它可能需要被反向移植到当前稳定版本、当前 LTS 或两者。如果你想获得这些上传权限，最好的方法是打包补丁并将它们提交给 SRU。一旦你第一次就提出了一些完美的建议，你就可以申请上传权限。