原文：Linux 内核的维护人员发现这些布丁没有太大意义，所以回信说不会合并代码

问题：像Linux内核这种体量十分庞大的开源项目，可能代码有很多需要改进的部分且有大量的开发者想提交补丁，如此一来审核工作会变得十分困难。比如审核人员过少导致审核速度过慢影响迭代速度，躲着审核人员过多导致人员杂乱会影响到安全问题。所以大型开源项目的管理人员是怎么组成以兼顾安全和效率呢？

原文：

Linux 社区的领袖 Linus 对此表示了不满：

“这很让人讨厌，因为大部分的补丁是有用的（通常补丁不是”无用的”或者“故意提交恶意代码”），所以从根本上来说，这种行为就是在浪费大家的时间。”

问题：开源项目管理者们如何判定和评估开发者提交的代码的有用性和安全性的？

原文：我现在已经记的不是特别清楚我第一次提交issue的时候，是个什么样的心情了 。大概是有一些紧张、激动吧。我花了点时间，很认真的写下了问题的原因，但是却又担心社区不给我反馈。

问题：如何理解、上手某一开源项目以达到能够提交issue、pr的水平？

原文：虽然我们无法干预市场，但产品的决定权却始终掌握在我们手中。我们希望打造一个优雅、健壮、美观的产品

问题：一个开源项目，基金会、项目管理者、开发者、用户之间是一个什么关系？

原文：因为最初开发的时候，我也不太确定自己这个方案的可行性，所以开发过程中的验证代码，我都暂存到了自己的私有仓库。最后确认可行之后，我还是把这部分的验证梳理了一下（不是完整的解决方案代码，但已经基本够用），并正式的进行开源，可能很少人会遇到类似场景，所以没什么人关注。

问题：开源自己的项目，怎么获得开发者们的关注，并如何管理这个开源项目？