据Home · DebugUself/du4proto Wiki中最小信息环, 所有的 issue 在关闭时都应转化为 wiki 或 DUW(怼周刊).

其中,对全体怼友长时间有效有用的内容,应该放在 wiki.

写好了 wiki,才真正的理解了一个问题,变成了自己的.

• 从 issue 到 wiki

格式	侧重点
issue	以解决问题为主，信息较乱。
wiki	给新人的讲解，指引行动，简洁完备。

• wiki 的章节体例(以下为二级标题)

  • 概述
  • 背景(意义)
  • 操作
  • 注意
  • 总结
  • 故事
  • 参考
  • 关联
  • 增补
  • 用时

• 像写说明书一样写 wiki

  • 重点是步骤(操作), 一步一步的说清楚
    • 大家都知道的不用写
    • 大家一定要知道的必须写
  • 步骤之后,如何让大家愿意照你的做? -- 在操作之前加上概述和意义.
  • 让读者记住你的步骤 -- 操作之后加个小结.
  • 如果不按这个步骤做, 会出问题和笑话. -- 简短的故事.
  • 生成文章参考了哪些前人的智慧 -- 参考
  • 还想知道更多? -- 关联 issue 和 wiki
  • 参与进来 -- 增补路径
  • 谁在这个 wiki 上花了多少时间,有事找谁 -- 用时
  • 清单式写作, 不是散文. 点和层级

• 在新的 issue 里公示 wiki 内容

  • wiki初稿，放在 issue，限定时间公示。

  • 公示

    • 题目格式: 24h[ANN][wiki]初稿公示: xx
    • 在 mailling list 里发布 #ANN# issue link
    • 在 小密圈中发布 #ANN# issue link

  • 公示完毕后发布

• 将你的 wiki 页面上传到仓库

  • clone 仓库的 wiki 到本地
    • git clone Adding and editing wiki pages locally - User Documentation
  • 上传
    • git commit 操作同仓库代码提交一致

• 将 wiki 页面链接放到侧边栏

  • 英文命名。

• 关闭 issue

  • 将 wiki 页面链接放到关联 issue ,即可关闭 issue, 包括公示 issue.

写出好文章本身一直就是宏大命题, 有人将自己的答案变成了一个年入过千万的课程

那么我们在持续写 维基 的过程中, 不断总结其中的经验/原则/工具/资源… 将写出好文章/手册这事儿说清楚, 本身带来的好处:

• 0: 逼自己更加有效率的加强已知弱点
• 1: 形成自身写作进化的路径
• 2: 量化/显示化你写作任务的工作量 ~ 文章质量的提高和事先作笔记和研究的时间/量呈正比
  • 拿出来给 UP 看, 就可以合理谈条件了哪…
  • 毕竟人家不明白一篇文章背后的工作量, 并不是坐那儿一想就有的
• 3: 形成原创方法论, 帮助有心的同事共同增长
• 4: 用有诚意的知识树吸引同盟军, 共同扩展写作视野和命题, 形成课题组, 产出加倍
• 5: 积累为原创课程内容, 未来转化为自己的付费知识内容
• 6: …

这其实, 才是输出是更残酷的输入的进一步扩展

像写说明书一样写 wiki 的操作, 这部分最重要,从这里起笔. 概要/背景/小结等各自的效用在操作部分写好后自然显现,添加即可.

• 可在本 wiki 上继续增补.
• 可在24h[ANN][WIKI] wiki 撰写指南公示 · Issue #82 · DebugUself/du4proto回复.

How2gitDUW · DebugUself/du4proto Wiki [禁止事项清单](https://github.com/DebugUself/du4proto/wiki/HbNotDoIt）

• 2017-04-26 发布 15 min
• 2017-04-25 根据 zoe 意见改稿 15 min
• 2017-04-25 wiki 初稿 40 min
• 2017-04-19 根据大妈建议，看其他 issue 怎么转 wiki, 改稿 80 min
• 2017-04-19 写初稿 75 min

.O.
..O
OOO