快速回顾

出席: eche|on, hottuna, orignal, str4d, susbarbatus, zzz

会议记录

20:00:05 <zzz> 0) 嗨 20:00:05 <zzz> 1) 上次会议遗留事项 http://zzz.i2p/topics/2093 20:00:05 <zzz> 2) 替补 kytv 的角色与服务 http://zzz.i2p/topics/2098 20:00:05 <zzz> 3) 0.9.26 规划更新 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:00:05 <zzz> 4) HOPE 筹备 http://zzz.i2p/topics/1968 20:00:05 <zzz> 5) 对月度会议与项目管理三个月后的简要回顾 20:00:10 <zzz> 0) 嗨 20:00:12 <zzz> 嗨 20:00:38 <zzz> 1) 上次会议遗留事项 http://zzz.i2p/topics/2093 20:00:55 <orignal_> 嗨 20:01:00 <zzz> - Reseed 活动准备,截止一月底: 20:01:00 <zzz> ** 由 Sadie 联系备选人员以讨论(未完成),新日期 4 月 5 日 20:01:11 <zzz> sadie,情况如何? 20:02:10 <zzz> - 加强网络——主页及附加页面 20:02:10 <zzz> ** str4d、gravy、cacapo:增加使用场景,我们擅长什么,更多“激情”和“内容”,添加/突出 Bote,一月底前未完成,str4d 在 3 月 6 日前把使用场景加到网站,关于“激情”等的更多更改在 4 月 5 日前完成 20:02:15 <zzz> str4d,情况如何? 20:03:06 <zzz> - 添加 I2P 的“故事”/ 历史 / 缘由 20:03:06 <zzz> ** 由 comraden 编辑 / 打磨 / 增强 / 发布,截止 2 月底(未完成),新日期 4 月 1 日,草稿在 3 月中返给 zzz 20:03:11 <zzz> comradenosebleed,情况如何? 20:03:34 <str4d> 嗨 20:04:40 <zzz> 工单管理——目前是临时/即兴式 20:04:40 <zzz> ** 由 Sadie 评审,提出建议,或可能开始管理(何时?)(未完成),str4d 和 sadie 在 4 月 5 日前安排会议或提交报告(?) 20:04:50 <zzz> sadie,str4d:情况如何? 20:05:49 <hottuna> 嗨 20:05:59 <zzz> str4d 未完成——Android 0.9.24 于 3 月 3 日发布,3 月 6 日前整理 TODO 清单,3 月 6 日前完成路线图草案,3 月 5–6 日审阅 20:06:05 <zzz> str4d,情况如何? 20:06:33 <str4d> 我们讨论过了 20:06:41 <str4d> (抱歉,同时在参加两个会议) 20:06:54 <zzz> str4d 和 zzz 在 2 月 12 日前审阅 VRP 工单;将于 3 月 5–6 日路线图会议期间做出一些决定(zzz 已于 2 月 8 日完成,str4d 于 3 月 6 日前完成) 20:06:56 <str4d> 关于工单 20:06:57 <zzz> str4d,情况如何? 20:07:29 <zzz> sadie 和 anonimal 将在 4 月 5 日的会议上带来基于 Monero 0mq 的 CoC(行为准则)修改 20:07:36 <zzz> sadie,anonimal:情况如何? 20:08:25 <str4d> 我之前决定将需要分拣的工单状态设为“new”,我现在仍然认为这么做是对的 20:09:00 <str4d> 我也觉得为我们中的几个人设一个定期的时间来过这些工单会是个好主意 20:09:09 <str4d> 关于 android 20:09:59 <str4d> 还没发生,因为被构建脚本卡住了 20:10:17 <eche|on> uhh 20:10:54 <str4d> VRP 工单:还没做,因为我原本计划处理时生病了 20:11:00 <zzz> 很明显目前的项目管理风格不起作用,因为什么都没发生。我们继续吧,我把 5)放进议程是为了决定是否该继续月度会议 20:11:10 <zzz> 这些事项几乎全都已经 3 又 1/3 个月了 20:11:19 <str4d> 有件不在 zzz 清单上的事是:我完成了规范迁移,提案的迁移也进行得不错 20:11:37 <zzz> 有关规范/提案的好消息,干得漂亮 20:12:09 <str4d> 所以我认为,说“什么都没发生”不正确,只是优先级发生了不在当前项目管理风格中体现的转移 20:12:17 <str4d> 所以是的,我们需要优化 20:12:20 <zzz> 好的。换个视角不错 20:12:25 <zzz> 1)还有别的事吗? 20:13:04 <str4d> 其他人请看,提案相关内容在 http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec/proposals - 请审阅并评论 :) 20:13:26 <zzz> 2) 替补 kytv 的角色与服务 http://zzz.i2p/topics/2098 20:13:34 <zzz> 他做的事大概有 20 来项 20:13:44 <str4d> 我这边没别的了 20:13:47 <str4d> (我确实做了 I2P Android 的工作,只是还没发布) 20:13:55 <zzz> 我一直专注于我认为最优先的事——Launchpad 和 Debian 20:14:14 <zzz> 还有其他人也在研究别的事情,我们在 .25 中替换了控制台首页的几个链接 20:14:33 <zzz> 在我看来,接下来最重要的是 Tails 维护者 20:15:06 <zzz> 这里有人既了解 Tails 又懂 Debian 打包并能帮忙的吗?如果没有,我会尽快在 Twitter 上发公告 20:15:24 <zzz> 我们可能会在两个月后的下个版本中被 Tails 删除 20:15:32 <zzz> 我记得是 2.4 20:15:50 <zzz> 这超过我能处理的范围。我不会做这件事。 20:16:02 <str4d> 唉 20:16:19 <str4d> Tails 至少需要什么 20:16:19 <str4d> ? 20:16:20 <zzz> 工作是拿我做的 Debian 打包,微调/整合进 Tails,反复测试测试测试,外加一堆现有的 Tails I2P 工单 20:16:49 <zzz> 我记得 kytv 写过一篇详尽说明,从 zzz.i2p 上的 kytv 主题有链接 20:17:04 <zzz> 基本上 Tails 的输入是一个 deb 包 20:17:19 <zzz> 但我觉得他们有一堆积压的不满 20:17:25 <eche|on> 在 Twitter 上发招募 20:17:33 <str4d> Twitter +1 20:17:35 <zzz> 还有谁对替代 kytv 的事项有进展要汇报吗? 20:18:07 <str4d> 自从一两周前我在 IRC 提过以后,我在 Buildbot CI 服务器上没有更多进展 20:18:23 <str4d> 我会在这个周末再做些工作 20:18:42 <zzz> 好。清单上还有很多,每个人都挑一件重要的做吧。 20:19:02 <zzz> 2)最后一次征询 20:19:46 <str4d> 如果没有其他人做,我“可能”会接下 IRC 机器人/中继。现在可能性不大。 20:20:34 <zzz> 我觉得 deb 构建还算不错,但仍有一些问题,比如 Jessie 上的 ARM,我今天可能修了,也可能没修 20:21:19 <zzz> 3) 0.9.26 规划更新 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:21:33 <zzz> 好的,我想先做 3a)时间安排,然后 3b)GMP 6 20:21:38 <zzz> 3a)时间安排 20:22:03 <zzz> 路线图写的是“五月”,而从上次 3 月 22 日的发布算起 6–7 周就是五月上旬到中旬 20:22:36 <zzz> 在一个月前的路线图会议上,我们制定了一个雄心勃勃的计划,包括地址簿订阅协议 20:23:16 <zzz> 但第二天一切都崩了,因为 kytv 的东西都挂了,而且他回来的可能性越来越小 20:23:36 <zzz> 所以我还没开始任何与 26 相关的工作。过去 2–3 周我全职在做 Debian/Launchpad 的事 20:24:01 <str4d> 从现在起大约七周是五月底。你觉得可行吗? 20:24:15 <str4d> (既然 Debian 的事情基本可控了) 20:24:19 <zzz> 那会把 26 推到六月,而且会远远超过 Tails 2.4 的截止 20:24:37 <str4d> 唉 20:24:37 <zzz> 五月底有可能,但每天都在变得不太可能 20:24:42 <str4d> Tails 的截止是什么时候? 20:25:11 <zzz> 不清楚。我已经再次要求他们自己拉取 25(他们之前已经拒绝过一次) 20:25:23 <eche|on> 我觉得六月没问题,因为 Tails 目前在评审 20:25:45 <zzz> 他们看不到 Tails 上 I2P 的使用情况,也没有听到任何呼声,因此觉得得不偿失 20:26:18 <eche|on> 是的 20:26:33 <zzz> 通常对于地址簿订阅协议这样的重大功能,我会在“上一个”版本发布前一周就完成,准备提交 20:26:54 <zzz> 所以已经落后 3 周了,再加上至少几周的开发时间,总共要落后 5 周 20:27:39 <zzz> 以上就是现状。我还没在官方路线图上发布任何更新,但很快需要这么做 20:27:49 <zzz> 关于 3a)时间安排还有什么? 20:27:58 <str4d> 我们原计划在 0.9.27 里放什么? 20:28:16 <zzz> 看上面的路线图链接 20:28:31 <zzz> 早期的 ntcp2/dh/pt 20:29:18 <str4d> 我仍然认为需要按照上面的顺序来,因此我们可以把地址簿订阅协议推到 0.9.27 20:29:27 <str4d> 这能给你五月的时间来做 20:29:47 <zzz> 但还没有 .26。什么都没做。除了 deb 更改外,里面现在什么都没有 20:29:50 <str4d> 然后 .26 可以做一些 CRL(证书吊销列表)以及通用清理 20:30:08 <zzz> 在有人(包括我)真正做出点东西之前,没有可发布的内容 20:30:27 <zzz> 我还得抽几天时间去报税 :) 20:30:37 <zzz> 关于 3a)时间安排还有什么? 20:30:55 <eche|on> 别过分拘泥于既定进度表 20:30:56 <str4d> 我这边有一些初步的 UI 调整,是我和 sadie 讨论后得出的,我可以先应用 20:31:20 <zzz> 3b)GMP 6 20:31:25 <str4d> (不是我计划的大改版,而是一些常规优化) 20:31:50 <zzz> 经过大约 15 个月的工作,tuna 和我差不多准备好把 gmp6 分支在 26 合并进主干了 20:32:05 <zzz> tuna 在过去 6 个月里构建了大约一百个二进制文件,等待提交 20:32:25 <zzz> 用各种方式构建——VM、原生、Microsoft、借来的机器等 20:32:53 <zzz> 按惯例,我们在提交每个二进制文件时都会附上详细的构建环境说明(编译器版本、系统 OS 细节等) 20:33:13 <zzz> 不幸的是,tuna 没有保留任何构建的记录。 20:34:06 <zzz> 那么问题是,我们要不要从头再来(可能要花 6 个月),或者我只构建 Linux 的二进制并忽略其他的平台,抑或其实不需要这些记录,直接采用 tuna 已经做好的所有东西? 20:34:08 <eche|on> 有机会重做吗? 20:34:47 <zzz> tuna 说不可能。任何人都可以构建 Linux 32/64 的二进制,但其余的都是问题 20:35:00 <eche|on> 好问题,这种情况下:要么重做,要么接受,没中间道路 20:35:25 <eche|on> 我们需要 Mac、Win 和 ARM 的 GMP 相关内容 20:35:29 <zzz> tuna 最后告诉我是要么接受要么拉倒,他这边已经做完了 20:35:54 <zzz> 即便构建很快,测试也很慢 20:36:25 <str4d> 我们有没有把测试流程写在某处? 20:36:54 <zzz> 如果你去 http://zzz.i2p/topics/1960 的最后一页,他已经提交了他仅有的全部构建说明 20:36:56 <eche|on> (顺便说一下,我们之前也接受过没有说明的其他内容) 20:37:07 <str4d> 因为这听起来就该放进 CI 服务器里 20:37:38 <zzz> 他已经更新了关于如何构建的 README。该主题里也有一些如何测试的信息,我也摸索了自己的方法 20:38:07 <zzz> 回想一下,过去 6 个月他发布了 13 个版本的二进制集合 20:38:36 <zzz> hottuna,你还有要补充的吗? 20:38:37 <str4d> 如果有人能写出一套测试方法,我可以把它做成 Buildbot 里的一个构建类型 20:38:58 <str4d> 接下来就是找机器挂上去。 20:39:08 <hottuna> 等一下 20:39:24 <str4d> 我在想我们可能该弄台 Mac,放在某处常年运行,作为 buildslave(构建从节点) 20:39:44 <hottuna> eche|on:关于重建:不是不可能,但对我现在来说工作量太大,远超负荷。 20:40:02 <str4d> 不用太贵,但能真正用来凑齐“三件套”(只要我和 eche 把 VM 的事情理顺,我们就会有 Linux 和 Windows 的 buildslave) 20:40:10 <eche|on> hottuna:有没有可行的重建方法? 20:40:27 <zzz> 即便 100 个文件明天全部构建完,测试也需要 3 个月 20:40:39 <hottuna> 有一份 README 文档,里边“应该”包含你需要的一切。 20:40:48 <str4d> 至少,我们已经从 hottuna 对各脚本的改进中受益了 20:41:10 <str4d> 不过另一个问题是,如果我们现在重建,要不要直接跳到 6.1 20:41:11 <zzz> 另外 cpuid 代码本身也有大量变更 20:41:23 <hottuna> str4d:脚本现在还不完美,但总之更好了。 20:41:23 <zzz> 对,可能 6.1 20:41:25 <str4d> 没错 20:41:30 <hottuna> str4d:如果我们重建,应该直接跳到 6.1 20:41:44 <eche|on> 新代码工作正常吗? 20:41:57 <hottuna> eche|on:据我们所知没有 bug(哈!)。 20:42:07 <zzz> 当然在 debian 构建里我们是动态链接,所以如果已安装你会得到 6.1(这也提醒我,我们还没测试过 gmp 6 的动态库) 20:42:10 <str4d> 我不太确定脚本需要改多少来做 6.1,但我希望基本可以直接替换 20:42:14 <eche|on> 如果测试没问题,就把它包含进去。然后在旁路重建 6.1,相关信息稍后再补全 20:42:38 <eche|on> 在我看来,我们已经测试得相当不错了 20:42:51 <hottuna> eche|on:棘手的并不是跑脚本本身。拿到机器、搭环境和测试才是困难/缓慢的部分 20:43:03 <eche|on> 是啊 20:43:13 <str4d> hottuna,这正是我想放进 CI 的东西 20:43:15 <zzz> 回到最初的问题。我们要不要丢掉 6 个月的工作(实际上从 2015 年初就开始了),还是可以在没有具体说明的情况下接受现有的二进制? 20:43:25 <str4d> 你觉得用了多少种不同的机器? 20:43:37 <zzz> 先把 CI 等暂且放一边,先决定我们是否有问题 20:43:52 <hottuna> str4d:应该基本是替换即用,再加上一两个目标。没理由不支持 gmp 支持的最新架构 20:44:13 <str4d> zzz,我倾向于在我们计划迁移到 6.1 的前提下接受这些二进制 20:44:24 <hottuna> str4d:大约 6 种不同的环境 20:44:29 <zzz> 6.1 在我们今年年底的路线图上 20:44:39 <zzz> 当前的二进制是 6.0 20:44:41 <str4d> 接受这些二进制会有哪些连带影响? 20:44:41 <hottuna> str4d:交叉编译时不一定需要那些机器 20:44:51 <str4d> 1)它们会进 mtn 20:45:01 <zzz> 另外别忘了,它在某些硬件上能带来很大加速,并且实现常数时间 20:45:17 <str4d> 2)它们会被打包进相关更新和安装文件 20:45:21 <zzz> “连带影响”= 坏事? 20:45:28 <str4d> 2a)让更新文件体积大幅增加 20:45:44 <str4d> 3)如果在某些系统上坏掉了,会怎样? 20:46:03 <str4d> 反正 1)我们本来也打算这么做 20:46:26 <zzz> 只有在会立刻用于 .26 的情况下我们才提交这些二进制。 20:46:28 <str4d> 2)同理,不过 6.0 的二进制之后会被 6.1 替换,所以不算大问题 20:46:37 <str4d> 我担心的是第 3 点 20:46:43 <zzz> 只提交要发布的二进制 20:47:00 <str4d> 3a)是否有现成代码来检测故障状态? 20:47:04 <zzz> 3)对任何改动来说都是通用风险 20:47:19 <zzz> gmp 出问题通常会导致 JVM 崩溃 20:47:26 <str4d> 3b)有没有办法回退到较旧且可用的 libjbigi? 20:47:44 <str4d> (自动或手动都行) 20:48:00 <str4d> 比如我们能否改名旧的 libjbigi,这样一旦出问题,我们可以告诉用户“去把这个文件改名” 20:48:22 <zzz> str4d,你是在探讨我们是否根本就不该改 jbigi?这些影响对任何更换 gmp 的行为来说都是通用的 20:49:14 <str4d> zzz,你担心的是我们不知道这些二进制的精确来源。我的理解是,如果出问题,就会更难追踪根源。 20:49:27 <str4d> 所以我在考虑缓解策略 20:50:00 <zzz> 我们可以不在 26 的更新中包含 jbigi.jar,这样只有新安装会得到它。那会是更慢的滚动发布。 20:50:25 <zzz> 新安装 + Launchpad/Deb 20:50:57 <zzz> 通用的修复是删除 libjbigi.so 和 jbigi.jar,然后就不使用它们了 20:51:01 <str4d> 这不管怎样可能都是个好主意 20:51:30 <str4d> 先发给新安装,如果没听到问题,再在下个版本的更新里推送。 20:51:43 <zzz> 我想 tuna 的意思是反正没有可重现性。全都是借来的机器和早就不在的 VM 20:52:23 <zzz> eche|on,hottuna 用来做 win 构建的那台机器的系统和 MSVC 信息还在吗? 20:53:10 <zzz> tuna 完全不愿做任何追溯,但他不是还借过 sadie 的笔记本吗?还是说这都没用了,因为期间可能升级过? 20:53:24 <eche|on> 他能访问我 KVM 宿主上的那台 Windows 10 机器。我可以登录查看 20:53:33 <str4d> 嗯,这就是我想在 Buildbot 上用可追踪的构建服务器做 6.1 构建的原因。 20:53:57 <hottuna> zzz:我借了两位朋友的两台 OSX 机器 20:53:58 <eche|on> 我完全没有改动那个 VM 20:54:33 <zzz> 没有人愿意领走一台我们买单的免费 Mac,因为没人想当“Mac 负责人” 20:54:51 <zzz> 所以真正缺的是时间和人手,不是钱 20:55:17 <hottuna> zzz:我只是不想背着这些设备到处跑。 20:56:01 <zzz> 以下是 hottuna 的完整构建说明: 20:56:03 <zzz> 构建说明 jbigi: 20:56:03 <zzz> ------------------ 20:56:03 <zzz> Windows:交叉编译,Linux 主机。编译器:GCC 20:56:03 <zzz> Linux:原生构建。编译器:GCC 20:56:03 <zzz> FreeBSD:原生构建,VM。编译器:GCC 20:56:03 <zzz> OSX:原生构建。编译器:GCC 20:56:03 <zzz> 构建说明 jcpuid: 20:56:03 <zzz> ------------------- 20:56:03 <zzz> Windows:原生构建。编译器:MSVC 20:56:03 <zzz> Linux:原生构建。编译器:GCC 20:56:03 <zzz> FreeBSD:原生构建。编译器:GCC 20:56:03 <zzz> OSX:原生构建。编译器:GCC 20:56:17 <zzz> 这些是否足够,还是我们要重头再来? 20:57:14 <str4d> 鉴于我们计划在年内迁移到 6.1,而且这些二进制已经经过了合理的测试,我倾向于说可以。 20:57:41 <zzz> 有反对意见吗? 20:57:45 <eche|on> 这至少是个开始,但就“Tor 可重现构建”的标准而言,这算不上什么。我们要追求怎样的标准? 20:58:03 <hottuna> 没有 20:58:34 <eche|on> 我希望把它们以“临时”标记包含到新安装中。我知道这很辛苦。 20:59:14 <zzz> 基本上目前测试已降为零。获得更多测试的唯一办法是把它们进主干,然后发布。 20:59:17 <susbarbatus> 抱歉插话;我有多台 Mac,当个 Mac 或 BSD 的负责人没问题。会后若有人能告诉我需要做什么,我可以评估一下自己是否有足够知识/是否能学会从而参与贡献。 20:59:29 <zzz> 太好了,susbarbatus 20:59:44 <str4d> susbarbatus,那太棒了 20:59:47 <zzz> 好的,那就请 hottuna 把它们提交进来 20:59:53 <eche|on> zzz:是啊,我们从没说过发布是 100% 安全且完美的^^ 21:00:05 <zzz> hottuna,分支是 i2p.i2p.str4d.gmp6(不是 i2p.i2p.zzz.gmp6) 21:00:17 <hottuna> 好的 21:00:38 <zzz> hottuna,别忘了对需要移除的文件执行 mtn drop。完成后,目录应与您 v13 的 zip 中的内容完全一致 21:00:50 <zzz> 关于 3b)还有别的吗? 21:00:55 <hottuna> 要把我们没构建的平台的旧 jcpuid/二进制删除吗? 21:01:09 <str4d> susbarbatus,我想要搭的是一台 buildserver(构建服务器),如果你能保证有一台 Mac 常年运行,并在出问题时能回答问题/协助。总体来说不需要你投入太多,因为构建服务器会被自动控制 :) 21:01:28 <zzz> 我记得 hottuna 的提议是 v13 就是要发布的内容,分毫不差。 21:01:38 <zzz> 如果你愿意,会后我们可以再复核一次 21:01:38 <str4d> 或者如果不能常年运行,至少能在构建服务器的配置里方便地启动 21:01:51 <hottuna> zzz:太好了 21:01:54 <str4d> (buildmaster(构建主控)会处理那些不一直在线的构建服务器) 21:02:12 <zzz> 先把构建服务器的话题搁置,进入 4) 21:02:22 <zzz> 4) HOPE 筹备 http://zzz.i2p/topics/1968 21:02:23 <susbarbatus> str4d:没问题。我可以把我大约 2012 年的 Mac mini 接起来用。它比较慢,但不会跑别的。 21:02:24 <str4d> ACK 21:02:33 <str4d> ^5 susbarbatus :) 21:02:52 <eche|on> HOPE——我有一张可以使用的门票 21:02:57 <zzz> 我这周和 Lance 见过。提议仍然是由他提供一间小型会议室全天使用,时间是在 HOPE 的前一天或后一天 21:03:04 <zzz> 即 7 月 21 日或 25 日 21:03:22 <zzz> 我向他强调我们很快就需要一个确定的日期和承诺,好订机票 21:03:46 <zzz> 这不会对公众开放。仅限受邀,5–6 人,只是用于路线图会议等的聚会 21:03:51 <str4d> 目前我不能保证能到场,尽管到那时我有小概率会在美国 21:04:00 <zzz> 另外我们向他介绍我们在做什么,反之亦然 21:04:30 <zzz> 目前确定的是我和 sadie,comradenosebleed 和 lazygravy 是可能。还有谁? 21:04:49 <zzz> 你们最晚需要在什么日期敲定行程? 21:05:33 <zzz> 如果只有我和 sadie,或许我们可以取消整个活动,但先看看情况 21:05:39 <zzz> 有人吗? 21:06:04 <zzz> hottuna 来吗? 21:06:07 <str4d> (一切取决于我的论文答辩何时安排,目前还不知道) 21:06:09 <str4d> (还取决于其他签证相关事项) 21:06:17 <str4d> 如果我的答辩在那之前,我想去(即便只是路过转机) 21:06:17 <eche|on> 我有兴趣,但负担不起机票和酒店。尤其如果我们稍后在 can 见面的话 21:06:17 <str4d> 所以大约一个月后再问我 21:06:45 <zzz> 好的,我会继续催 Lance 尽快敲定,也希望人手能到位 21:06:50 <zzz> 4)最后一次征询 21:07:00 <hottuna> zzz:对我来说时间上很尴尬。我 7 月 16 日要在欧盟参加婚礼。 21:07:15 <hottuna> 我觉得我现在不敢承诺。 21:07:20 <zzz> 太好了,回程路过纽约吧 :) 21:07:26 <hottuna> (或者如果必须现在定的话,那就暂时不承诺) 21:07:33 <hottuna> 嗯哼.. 21:07:44 <hottuna> 这个主意不算差 21:07:47 <zzz> 5)对月度会议与项目管理三个月后的简要回顾 21:07:59 <str4d> 那就把我记作聚会“希望能到”,HOPE“可能到不了”(因为我现在不能确定是否需要门票,但如果恰好在那儿,会用掉一张多余的) 21:08:26 <zzz> 好的,从我的角度看这完全行不通,几乎没有任何行动项被完成。那我们是还能修正,还是应该停止月度会议? 21:08:40 <str4d> 我觉得可以修正 21:08:42 <zzz> 如果没人做事,就无事可管。虽然没那么糟,但很接近了 21:09:11 <str4d> 至少我认为月度会议是有用的 21:09:30 <zzz> 目标还包括把项目管理移交给 sadie,但她连会议都没来,这也脱轨了 21:09:32 <hottuna> 我同意 21:09:44 <str4d> 她以为早一小时 21:09:49 <str4d> 她现在在另一个会议 21:10:19 <str4d> (她提前一小时到这儿,结果没人说话) 21:10:41 <zzz> 当然,谁不喜欢不用主持的会议呢。但我每个月在这儿问三个月前承诺的事情是否完成,感觉自己像个傻子。我累了。 21:10:49 <str4d> 我已和 sadie 讨论过,我们现在设立了每周会议,来跟踪我们共同在做的事项 21:11:19 <str4d> zzz,那就不要把会议的重点放在“你把这件事做了吗”上 21:11:36 <zzz> 也许我说得太严重,但在缺乏进展且 kytv 消失的情况下,我认为我们麻烦很大 21:11:40 <hottuna> zzz:什么时候把工作移交给 sadie? 21:11:40 <str4d> 我认为月度会议应该更多用于重新评估优先级和重组安排 21:11:58 <zzz> 好,那我们如何让大家按承诺推进? 21:12:13 <str4d> 而“你把这事做完了吗”需要 a)更强的个人责任感,b)更多一对一的沟通 21:12:30 <hottuna> zzz:无论如何都称不上好,但说“麻烦很大”可能有些夸张。 21:13:02 <str4d> 以我为例,我已和 sadie 安排了每周会议来督促自己,并给了她我 I2P 待办清单的访问权限,便于她帮助设定优先级 21:13:07 <susbarbatus> str4d:我觉得重点在于,如果大家都能守诺/履约,zzz 就不必问“这事做了吗”;)。 21:13:12 <str4d> (到目前我们只开过一次会,我还要看看效果如何) 21:13:17 <str4d> susbarbatus,没错 21:13:50 <str4d> 我们需要足够灵活,以应对大家是在本职工作之外出于兴趣/志愿地做这些事的事实 21:14:13 <zzz> 对。我的机制是,当你完成某事后,在 zzz.i2p 的会议主题里汇报,这样我们就不必占用会议时间 21:14:15 <str4d> 但也要强调,如果有人没把事做成,那就是没在帮忙 21:14:28 <zzz> 只有当人们既没完成也没汇报时,我们才不得不在这里浪费时间 21:14:42 <str4d> 而且把事项转交他人要比无限期阻塞更好 21:14:54 <str4d> (说这话的人自己正把 I2P Android 无限期阻塞着 :P) 21:15:19 <zzz> 所以 str4d 和 sadie 搭建了一个并行的、非公开的项目管理系统作为试验。这很有意思,但当然不清楚它与我在做的事如何衔接,或者我是否还该继续做 21:15:55 <str4d> zzz,这是更大图景中的一部分 21:16:28 <str4d> 正如我上面所说,把“你为什么没做这个”放到月度会议上并没有我们想的那么有用 21:16:35 <zzz> 因此,通过我的论坛以及在月度会议上点名批评的项目管理方式,我准备宣布失败 21:16:50 <str4d> 因为如果前三周什么都没做,最后一周也不太可能完成 21:17:21 <str4d> 因此我认为对有未完事项的人进行更定期的快速检查更好,这正是我和 sadie 正在尝试的 21:17:34 <zzz> 目前我不认为我能拿回 comradenosebleed 的草稿、拿到一份基于 Monero 0mq 的 CoC(行为准则)、把使用场景放上网站,或者发出一个 Android 版本——至少在任何具体日期之前都不太可能,不管定得多远 21:18:10 <zzz> 所以我建议停止对行动项的月度回顾。照例,在开源里人们会做或不做他们想做的事,在这里要说服任何人去做任何事都非常非常难。 21:18:36 <zzz> 人们会做他们想做的事,而我手里的胡萝卜和大棒都不奏效 21:19:50 <str4d> 不过我投票保留月度会议,并用它来根据过去一个月已经完成的事和发生的事持续调整优先级(例如在 kytv 之后我们刚刚对 .26 所做的调整) 21:20:56 <susbarbatus> 嗯,那个赏金系统目前运转得怎样?比如,它是一份带付费激励的精炼公开清单。大家还会关注吗? 21:20:59 <susbarbatus> 我想提的是:针对任务的微支付怎么样。 21:21:03 <str4d> 同时,如果有人同意做某件事,也应该同意就进展告知 sadie,或者至少提供一个渠道让 sadie 能提醒/催促他们 :P 21:21:21 <zzz> 好的,那么我提议辞去项目经理,由待定的某种/某人替代。我们保留月度会议,但不再审查行动项 21:21:54 <zzz> 下次会议将于 5 月 3 日(周二)举行 21:21:58 <zzz> 关于 5)还有别的吗 21:22:10 <zzz> 本次会议还有其他事项吗? 21:22:35 <str4d> 我没有了 21:22:53 <zzz> 感谢大家,今天会议很长 21:22:58 * zzz *bafs* 会议结束了