项目启动方案草案 V1

[neruthes]

背景

稍早前我们针对本年度官方网站改版事宜开展了一些讨论，就人员配置、宏观目标等议题形成了基本共识，留下了高保真原型图等前期成果。

@dextercai 被选举为项目主理人；@MingcongBai 和我将会积极贡献、协助推进。

我希望我的 UX 和 PM 背景能够为本项目的规划和执行起到积极作用，特此撰写本启动方案草案，以求促进需求分析、roadmap、workflow 等工作落地。

工作流

考虑到各个参与者的生活方式、时间安排、工具习惯，我们主要通过本 repo 的 issues 开展工作沟通，参考邮件列表的用法。

在具体的工作中，我们参考敏捷、瀑布流等经典实践，基于 issue 记载工作任务，基于 milestone 发版。

Git 使用实践，包括如何分配 branch、如何使用 tag 等，由主理人 Dexter 自行规定。

Roadmap

现在可以粗略规划 roadmap 如下：

• 需求整理：在高保真原型的基础上细化各部分需求，涵盖功能、美学等方面。
• 技术选型：选择一套合适的静态网站构建工具，以及选择一套合适的前端排版框架。
• 实质开发：完整 deliver 大部分已知需求。
• 后续迭代：不再严格绑定需求文档与实现，沿用 issue + PR 的开源社区惯例。

当前工作重点

我主张当前阶段我们的工作重点是需求整理。

我负责编撰《产品需求文档》，@dextercai 和 @MingcongBai 负责审议，总结已知的功能需求。

与此同期，@dextercai 可以基于相对有限的需求信息制定技术选型方案，编撰《技术选型文档》，包括前端、后端、部署等信息。

我建议将以上文档放在 repo 内的 /devdocs/{ProductReq,TechDesign}.md 路径。并且，可以通过 PenTeX 生成 PDF 产物。

评议与修改

本文件仅为初步草案，请在 issue 评论区参加讨论、推动修改，争取在实质开工之前就以上议题形成共识。

[MingcongBai]

目前我们只对实现思路和可能出现的问题进行了初步沟通，突然有这样一大份所谓工作计划实在是令人感到不解；而且，在大家时间都有限的情况下，为什么要求要编写正式文档？

1 中已经记录了目前需要考虑和寻找答案的具体问题，将细节补充好就行了；现在要求编写这些内容为时过早而且难说意义很大，项目本身需要提供给部署者和后续维护者的信息恐怕更重要：

• 部署文档：依赖和流程
• 开发文档：说明内容组织方式和参与方式

总之，目前为时过早，而且这样正式的所谓企划书，在人员有限的情况下怕是徒增工作

在提出这类要求前，麻烦先以问题的形式与其他人充分讨论，而不是用这样的 issue 提出指令

[neruthes]

@MingcongBai

针对以上意见，在此答复如下：

1. 关于前期文档

将前期文档视为一种项目管理投资，通常是赚的。设计问题和设计决议可以发生在 issues，但可查性会稍差，所以仍然值得将它处形成的决议汇总到文档内。

我打算亲自主导文档编撰汇总工作，符合「谁倡议，谁执行」原则。

2. 关于协商方式

我注意到之前的会议中尚未就项目工作沟通方式做出决议。我承认现在编撰本草案可能是过早的，协商工作流、路线图可能是过早的。当前我们可以将工作重点转移到协商如何协商。

之前的会议中，Dexter 表示其个人工作习惯倾向于 email，而非 Telegram 或 QQ。所以，我得出的诠释是将主要工作沟通放在本 repo 内。

在此基础上，之前的会议中，参会人员的主流意见是不设 discussions，所以我主张 issues 的性质应当理解为蕴含 discussions 的讨论沟通职能，不应狭义化为任务分配 todolist。

3. 关于问题形式

在发言形式方面，我尊重你对「问题」形式的偏好，并在此陈述对「草案」形式的申辩。

• 草案即是问题的合集。
• 在提出问题的同时披露自己的意见有助于提升沟通效率。
• 一份草案的存在不妨碍另一个人就类似议题编撰另一份草案。
• 这份草案不是要求，而是关于协商要求的倡议。

此外，我建议展开介绍「先以问题的形式与其他人充分讨论」这一主题，具体包含以下方面：

• 通过何种通信手段递交问题？
• 讨论成果记载在哪里？
• 好的问题应该满足怎样的 criteria？

稍后，我将遵循你的建议，以 Dexter 本人背书的 email 形式递交一些问题；欢迎就「哪些问题值得被问」一事提出建议。

[MingcongBai]

@neruthes 明白，但是目前的情况是，#1 中已经记录了昨天讨论中提出的问题，那些条目实际上才是需要添加具体想法和意见的；至于说文档的问题，你提到的原则很对，目前我认为最有建设性的做法是，你将掌握到的情况整理成文档记录起来

日常的开发沟通，目前还没有进行，因此是要问的；只是目前太早了点

前面我的答复可能比较直接，但是我的意见依然是，不要在流程问题上操之过急，我们有很多时间和机会，亦有必要，在工作沟通上进行磨合（如你所说，Dexter 牵头的工作不依赖 IM 的工作沟通，这是第一次）

[neruthes]

先前的邮件中，Dexter 表示：

特此留档，稍后我将迭代出《项目启动方案草案 V2》以反映这些意见。