# 协作式博客创作指南

# Implementation Plan

# 规划与时间

对象：就业人员或者科研人员

特点：每日能支配的时间大约 4 小时

时间节点：

周审阅会议时间：

• 周六晚到周日全天时段均可

• 默认为周六 PM 20:00

• 具体可进行调整，考虑到打工人的一般特质：

  • 交友
  • 恋爱
  • 探亲等

实验项目计划时间：3 weeks

预计时间消耗如下：

• 每周博客创作：2 ~ 13 h 不等 (因人而异)

• 每周阅读他人创作：20 mins ~ 1 h

• 每周 Review 审核：

  • 单篇讨论，交流，修订：约 20 分钟
  • 其他议题（下周内容，改进，体验等）约 20 分钟

消耗时间：3 h 40 mins ~15 h 40 mins

其中固定消耗时间： 1 h 40 mins ~ 2 h 20 mins （Review 审核时间）

预期目标：

• 每个成员高质量的博客：3
• 每个成员掌握其他的知识：6
• 阅读和理解，文字创作，交流表达能力提升

# 开题与撰写

我们需要进行以下步骤，请仔细阅读 Role & Duty 部分的内容，明白整个流程中的工作后，请认真填写以下文档：

文档地址：

然后我们会根据文档的填写情况进行调配，组成各个 Group，并预分配每个人负责的 Topic，接着就是开始各自创作的部分，

这里要注意，为了保证一致性，我们统一使用一样的编辑工具和管理工具来使得整体效率得到保证：

• 博客创作统一使用 Markdown 格式：Typora： https://typora.io/
• 博客中图表的管理统一使用图床：PicGo + Gitee：
  • https://github.com/Molunerfinn/PicGo
  • https://gitee.com/
• 博客中图标的绘制统一使用：Draw.io (PNG，SVG)
  • https://app.diagrams.net/
• 博客的最终上线平台使用：Gitbook
  • https://www.gitbook.com/

# 审稿与交流

审稿的流程如下：

1. 自负责人创作完初稿开始，Reviewer 可以登录 Gitbook 查看或者通过 PDF 查看内容，并在 Gitbook 进行 Comment 或者在 PDF 进行标注
2. 负责人应当在周审稿之前了解这些问题并准备相应的解答，也可在 Gitbook 中直接修改
3. 在周审稿当天的流程如下：
   • Review 先对博客中的问题和自己学习中的疑问提出见解和问题，进行记录汇总（先不做解答）
   • 负责人对所有记录的问题进行解答和解释，当 Reviewer 理解后讨论是否需要对文章的内容或者表述进行调整
   • Reviewer 对内容进行核心的提炼和总结，然后负责人把自己原先创作的总结部分展示，检验学习和预期是否一致
   • 完成修订后，将文章正式发布
4. 讨论其他议题
   • 之前博客中网友评论的留言解答
   • 本周操作下来的体验和感受等
   • 更好想法和改进意见

# Role & Duty

# 组队 （Group）

我们将一个 Group 作为一个实施的最小单位，为保证整体实施的可行性，做以下规定

• 每个 Group 的人数控制为：3
• 每个 Group 的组成：在理论验证阶段，队伍的组成将所有成员填写基本的信息来进行匹配
• 每个 Group 可以采用轮值的方式每周一个人来管理 Group 的 Gitbook 账号，管理内容如下
  • 需要在审稿之前，统计整个 Group 的 Comment 数量
  • 需要在审稿完成后，提醒并监督自己 Group 的博客修改完并上线
  • 需要在上线之后，不定期的查看评论，然后通过 Group 讨论进行回复
• 每个 Group 维护一个 Gitbook，其中 Gitbook 分为三个 Space
  • 每个 Space 负责人就是对应 Topic 负责人
  • 其他人员在非自己负责的 Topic 中均充当 Reviewer

Group 的概念是无领导小组，每个人都是负责人，每个人都是审稿人，都需要轮流完成 Group 的公共事务

# 负责人（Head Topic）

按照是时间线的顺序，介绍负责人的工作：

创作前：提前思考，自己想要整理的知识内容

• Topic 的内容是自己熟悉的，这里的思考更多是让自己理清楚已经掌握的知识的逻辑，并如何转化产生自己的知识
• Topic 的内容量需要进行规划，根据自己的时间和内容的难易，需要去划分好内容的多少

创作中：负责人是 Topic 的核心，负责 Topic 的核心知识生产工作，对此我们有以下创作要求大方向：

• Topic 的内容要求由浅入深
  • 浅的部分：是在引入这个内容以及相关的内容的对比和行业介绍
  • 深的部分：是具体到本次创作核心的知识，需要进行深入的讲解与介绍
• Topic 的内容要求准确性和实效性
  • 准确性：每一个引申的观点和每一个实际的例子都需要创作者进行求证
  • 实效性：内容应该是目前主流或者仍在使用的知识，而非淘汰的知识
• Topic 的内容性和表述的简洁
  • 内容性：
    • 行文的逻辑应该有保障，建议写作前先进行大纲的创作，避免跳跃式的表述
    • 内容结构应保持图文比例：3 ：7（即一个画面内文字内容占比不能超过 7 成）
    • 尽量使用自己的语言，如果他人的表述足够精炼也可直接使用，所有素材和资料查阅使用，均需要附在参考文献中
  • 简洁：
    • 避免长篇大论，内容空洞

创作思路上，负责人可以使用 WWH. 的行文逻辑

1. What：内容引入，知识定义等
2. Why：技术比较，行业对比等等
3. How：深入解析内容
4. . : 总括和提炼（审稿时加入）

创作后：负责人是 Topic 的维护者

• 作完成后，负责人需要将文章提交到 Gitbook 上，然后并将原版导出成 PDF 格式，并转发到各自的 Group 中

• 在周审核时，负责人需要先听每个 Reviewer 对内容的疑问和问题，然后进行解答调整。

• 同时需要准备一份总结和提炼，用于最后在审核时，来对比 Reviewer 理解提炼的内容和本人创作出发是否一致，

  最后进行调整后，在博客最后补上这一部分

  在博客创作时变可以写的，但是先不要放在提交的博客中）

• 完成最后交流和调整后，上线正式版的博客

• 当博客有评论的疑问时，进行解答和维护

# 审稿人 （Reviewer）

审稿人是作为一个学习掌握者的来推进二次创作的过程，他的职责如下：

• 在负责人创作完博客内容后，需要第一时间进行阅读和学习
• 然后在阅读学习过程中的一切问题进行记录与反馈
  • 发现问题便在 Gitbook 上进行 comment
  • 记录问题等到周审核时一起提出
• 在学习和阅读完后尝试去总结博客的核心内容，并转化为文字
• 在周审核上协助负责人对内容进行修改，与负责人交流，提高质量

# Evaluation System

实验完成后，我们需要一个体系来评价我们的方法是否时有效的，那么我们就会回到最开始我们开始这个项目的目的：

目的就是：更好的学习 + 积累影响力

那么评价系统也主要从这两个点出发，对我们的学习和博客质量进行评估，为了保证整个实验的客观，我们将在实验结束后才公布评价的全流程设计和结果，避免参与实验者，在得知评价方式后潜意识的重点倾斜，导致实验的不客观。