海豚需要帮助

我不知道此笔记可能有多重要，但我发现分享它很有趣。 这里的英文链接， http://freininghaus.wordpress.com/2012/07/04/dolphin-2-1-and-beyond/，我对这种语言的处理不好，所以请翻译人员帮我：

您可能在上周听说佩德罗·彭茨（Pedro Penz）不再是海豚的维护者。 我要感谢您过去几年来的良好合作。 和他在一起很高兴，我认为他的离开对KDE造成了巨大损失。

他将海豚的未来保养托付给我，所以我会尽我所能使他保持良好状态。 我认为易用性和稳定性是用户对Dolphin的最大评价，并希望确保保持这种状态。

我最重要的中期目标是吸引新的开发人员。 我认为这非常重要，原因有很多：

• 任何总线号较低的软件项目都将面临极大的危险。
• 我现在是维护者，但这并不意味着我可以增加在Dolphin中进行开发的时间。 我将尝试阅读所有输入的错误报告（请注意，可能需要一段时间，直到我看到最近报告的错误-甚至维护人员也有真实生活，有时去度假），并尝试重现可能复制了我的硬件和软件设置。 我还将尝试为每个版本修复几个错误。 但是，如果我必须独自完成所有主要的新功能，则无法实现。
• 我不喜欢一个人工作。 我一直很喜欢与Pedro和其他开发人员进行代码讨论，并且我非常喜欢所有提交都需要进行审查的想法。 显然，只有在定期为该项目做出贡献的人数超过一个的情况下，才可能对所有人进行补丁和审查。

为了使潜在的新贡献者更容易找到要解决的问题，我想共同努力，浏览所有过时的Dolphin错误报告，并为那些易于重现的报告分配有用的关键字。 现实生活会使我在接下来的几周内变得忙碌，但随后我将与Bug Squad取得联系并进行一些整理。 欢迎任何帮助。 我认为参加联合bug分类会议是开始为自由软件项目做贡献的好方法-正如我在上一篇文章中提到的，我参与KDE的开始是两年前的Konqueror。

当然，不仅要感谢代码贡献者，还要感谢其他领域的帮助。 这些包括：

• 在bugs.kde.org上分类漏洞报告。 将有用的信息添加到错误报告，指出重复项，要求报告者提供更多信息确实有很大帮助，从而减少了需要管理人员注意的错误报告的数量。 对于用户来说，即使经理忙于其他事情，他们的报告也可以得到快速响应，这对用户也有好处。
• 论坛中的用户支持。 看到一群热心的论坛成员能很快回答大多数用户的问题并解决其中的许多问题，真是太神奇了。 我认为这极大地改善了用户体验。
• 文档和翻译。 特别是BurkhardLück在保持Dolphin文档（和其他应用程序）井井有条方面做得很好。

如果您想总体上为Dolphin或KDE做出贡献，但又不想编写代码，那么参与这些领域之一是帮助项目前进的好方法。