697    一个做法就是制定发布日期，但让功能列表可以变通调整。

698    也就是说，在发布时允许舍弃部分功能。

699    这是稳定版内核开发的基本策略；艾伦·考克斯（Alan Cox，稳定版内核的维护者）定期发布稳定版，但是不承诺何时解决某个问题或者何时添加某个实验版的新功能。

700    另一个做法则是，锁定开发列表但不制定发布时间。

701    这是实验版内核开发的基本策略。

702    我们称之为：“做完再叫醒我（wake me up when it's done）策略”。

703    达·马可（De Marco）和利斯特（Lister）的研究表明这不仅可以提高软件质量，而且平均而言，它比任何“激进”或´保守”的策略都节省研发时间。

704    2000年初，我开始怀疑自己在前作（指本书的前期版本译者按）中严重低估了这种反发布时间（做完再叫醒我）策略对于开源社区的生产力以及质量的重要性。

705    1999年GNOME仓促1.0版的教训表明：即使是开源项目，为了赶进度而草率发布，也会严重影响软件质量。

706    有充分的理由可以表明：开发过程的透明化、´做完在叫醒我”的策略以及开发者自主选择研发对象的方法。

707    是影响开源项目质量的三个同等重要的作用力。

708    根据为我提供不同难易追踪途径的读者的推测，这种对多表象错误的追踪的复杂度呈´指数”分布（我理解为高斯或者泊松分布，而且这听上去很有道理）。

709    要是能通过实证绘出类似分布曲线的话，绝对很有价值。

710    假如其与等概率分布平行线大相径庭，那么即使独自开发也应该努力效仿市集模式。

711    也就是限定追踪问题的成因的时间，如果在限定时间内没有结果，那么就跳转到下一问题。