在过年的这几天, 为了从焦虑的工作中换一个心情, 我给我的 wechat-dump 项目添加了几个当年没做出来的功能, 解决了一些遗留问题. 意外的发现这个项目始于 2014 年末, 到今天已经超过十年了. 有多少人会有给自己十年前的代码补充新 feature 的经历呢? 突然有了一些感触想要写下来.

Meta 与 Google 内部的代码管理工具都支持一种被称作 "stacked diffs / stacked PRs" 的 workflow. 然而, 基于 git 的主流平台 (github, gitlab) 都不支持这种 workflow. 许多离开 Meta 后不得不使用 github 的朋友表示, stacked diffs 对于工程师是一个 "ultimate productivity tool", 我也深有同感. 这篇文章介绍一下什么是 stacked diffs workflow, 以及为什么它能够极大的提升团队开发效率.

这篇文章说说用户怎么提出好的 feature request / pull request, 以及维护者如何对待它们.

我听过不少人凭借爱好开源了自己的项目后, 却对 issue 太乱感到困扰, 甚至想干脆直接禁用 issue. 其实, 任何项目达到一定规模后, 如果不对 issue 进行适当管理, 都会使 issue 信噪比过低, 失去原本的功能.

这篇文章主要从 maintainer 的角度说说, 在具备规模的项目中管理 issue 的一些方法和原则.

报告错误 / 报 bug 是用户与开发者间最常见的一类交流, 也是常见的 github issue. 但是很多用户并不会科学的报 bug, maintainer 对此也缺乏引导. 因此这篇文章讨论如何科学的报 bug.

相比传统的邮件列表 / bugzilla/sourceforge 等开源平台, github 把开源社区交流的成本 / 门槛降的很低, 因此交流的质量也常常随之下降.

我计划写几篇文章, 从 用户 (User) 和 维护者 (Maintainer) 两者的角度写写开源社区中如何使用 issue/PR 进行沟通, 希望能够:

• 让普通用户学会提问, 学会以 maintainer 更容易接受的方式使用 issue/PR 做贡献.
• 给 maintainer 提供一些管理 issue/PR 的经验, 不要再为 issue 头疼.

开源工具链里有很多陈年小 "feature", 最初由于各种原因 (例如作为 workaround) 实现了之后, 即使语义模糊或设计不合理, 也因为兼容性被留到了今天.

Python's package management is a mess. I'm involved in a few open source projects and I often help users address their environment & installation issues. A large number of these environment issues essentially come down to incorrectly / accidentally mixing multiple different python environment together. This post lists a few common pitfalls and misconceptions of such.

This is a summary of the algorithms I used to write OpenPano: an open source panorama stitcher. You can find the source code on github.

vim 折腾了很久了, 好像有必要写一写我的 vim 配置.

大概就按照 vimrc 的顺序, 只挑一些好玩有趣的来讲好了. 完整的还是去 github 上看吧:

话说... 语法高亮非常悲催因为 highlight.js 不支持 vimscript 怎么办..

写了一个 hexo 插件: hexo-tag-vimhighlight, 现在可以用 vim 高亮代码了. 谢谢 @Alick Zhao 同学告知 vim 内置的 2html.