编程语言与软件工程2019journals.plos.org
帮助新来者成为开源项目的贡献者
Helping newcomers become contributors to open projects
入门 · 约 30 分钟读完前置知识：开源协作基础、Git/GitHub 使用经验
导读
这篇发表于 PLOS Computational Biology 的论文研究如何帮助新手成为开源项目的贡献者，探讨项目维护者可以采取哪些实践来降低新人参与门槛。文章在 HN 引发了大量关于开源项目维护实践和社区文化的讨论。
HN 关注点：HN 读者多为开源开发者和维护者，讨论焦点集中在项目应如何对待新人和 issue 报告，以及开源社区治理中的现实问题。
HN 评论精选
这几条评论里：支持 1 质疑 2 亲历 1
支持从维护者角度列出帮助新人参与开源的实用规则清单
根据个人经验，我希望项目遵循一些实用规则：README 开头写清项目是做什么的，并说明如何构建和运行；确保项目所有产物（包括网站和二进制发布）都能从源码构建并文档化；明确职责分配并尊重它，放手让人负责就不要微观管理；公开你的可用性，若要离开项目就在 README 顶部注明，不要断断续续地互动；及时回应 issue 和 PR——不等于全部接受，但哪怕说需要时间也要尽快回复；不要只因 bug 报告太旧就关闭，bug 报告要么可复现要么不可复现，坏的从一开始就关掉，好的别因时间流逝而关闭；文档方面一个例子胜过一打描述，善用语言提供的文档+单元测试结合机制；准备一份风格指南并在 README 链接；搭建 CI，现在有很多免费服务可集成 GitHub。
FeepingCreature查看英文原文
Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a task, don't micromanage them. * Document your availability. If you have to step away from the project, put this at the top of the README, even if it's temporary. Don't drip-feed interaction - be either on or off. * Be responsive to issues and pull requests. That doesn't mean accept everything, but answer quickly, even if just to say you need more time to look into it. Don't leave stale reviews open. * Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed. (This goes doubly for bug reports with advice.) * On documentation: one example is worth a dozen descriptions. Check if your language offers you a way to combine documentation and unittests; this is of high worth - take full advantage. * Have a style guide. Link it in the README. This saves you time in review. * Set up CI. Nowadays, there's plenty of free services that integrate with Github, so there's really no reason not to. (Combo bonus: CI with style check!)
亲历亲历者吐槽：24 年开发者也难融入开源项目，好项目不缺人、缺人的项目不值得做
坦白说：我做了 24 年职业软件开发者，却从未能真正进入某个开源项目（除了我自己开源的东西）。我想部分原因是：最值得参与的项目从不缺人，所以不需要向新人示好；而缺人的项目往往正是因为它们本身就不值得做。
semiotagonal查看英文原文
Confession: I've been a professional software developer for 24 years, and I've never been able to get my foot in the door for an open-source project (other than my own open-sourced license stuff). I think part of it is because the projects that are most worthwhile have no shortage of participants, so they don't need to extend any welcome to newcomers; and the projects that need participants often end up that way because they're not clearly good things to be working on in the first place.
质疑批评维护者把 bug 报告当麻烦而非关键反馈，优先做新功能
很多项目把 issue 和 bug 报告当作麻烦而不是项目生存所需的关键反馈渠道。我见过太多开源项目有严重 bug，但现有贡献者急于用'想要修复就付钱'来搪塞，却优先做满足自己智力好奇心的新功能。显然没人有义务做任何事，但如果你是因为在乎项目而参与，那么优先处理被报告的 issue、甚至感谢指出紧急 bug 的人，应该成为默认预期。
mlthoughts2018查看英文原文
I think some combinations of items 6 and 9 are often missing from projects where there’s a quick rush to view issues and bug reports as nuisance instead of viewing them as a lifeline of critical feedback the project needs for survival. I’ve seen it so many times where open source projects have critical bugs, but the existing contributors rush to play the false defense along the lines of “pay us if you want this fixed,” while prioritizing new features or projects out of intellectual curiosity instead. Obviously no contributor in an open source project _has to_ do anything. But at some level if you’re working on the project because you care about the project instead of burning the commons in a land grab for satisfying personal projects, then taking priority from reported issues and even thanking people for pointing out urgent bugs whose fixes should supercede the fun features of some planned release has to become the expected default.
质疑认为公开的 CoC 和治理结构会被别有用心者武器化
开源项目（或任何大型协作）现在面临一种新的危险：有人会在网上攻击你的作品、制造能毁掉人的大场面，只为在 Twitter 上显得正义或在某些圈子出名。类似从铁轨偷金属的窃贼，他们造成的损害远高于其所得收益，应像有害元素一样被抵制。可悲的是，公开明确的行为准则和治理结构反而给了这些人武器——本来按个案处理的问题，现在会有毫无利害关系的第三方用你自己的 CoC 来攻击你，只为赢得网络声望。
ermir查看英文原文
Open source projects (or any large collaboration) now have a new type of danger that many are unprepared to handle, in that there are people online who will shit on your work or make a giant spectacle that can ruin people just so that they can appear good in Twitter or make some kind of name for themselves in certain online circles. Similar to thieves who steal metal from railways, the damage they cause is far higher to the benefit they get, and so they should be resisted like the harmful element they are. Sadly, having an open and explicit CoC and governance structure gives these people a weapon to use against you. Now instead of dealing with your problem on a case-by-case basis, you will have third parties, who otherwise have no stake, interpreting your own CoC against you just to win some internet cred.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2019Hacker News 讨论帖203 分 · 96 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选