jimmylv.github.io
jimmylv.github.io copied to clipboard
基于 GitHub Issues 的卡片大法实践
对于我来说,原来好几年前我就在使用双向链接了,即GitHub 的issues之间能够双向链接,并且每个卡片其实是有着完整的时间线的。
只是说现在的网络环境下可能会有点儿慢,跟 Roam 的差距就只在于outline的编辑体验啦。
Outline 的编辑体验,可见即可得,GitHub 还是做不到,那就依然 Roam Research 牛皮,果然用了就回不去了 😂
而且每次都是问题导向,把新的内容补充到某个 Issues 的 comments 里面
再次感谢GitHub,其实我还想梳理一下GitHub额外的一些特性功能:
- 比如说努力程度的体现
- 工程化的看板实践
- 移动端App的支持(网络有时有问题,强行退出时会有保存)
当然,还包括跟其他工作流之间的集成,从阅读的源头说起,就两个
- 得到 (知识服务商)
- MarginNote (我的私人书架)
其实网络的限制会让我更有动力把问题在一个comment或issue里面说清楚。
#375 所以说,GitHub Issues 本身就是互相双向链接的,而 GitHub 还能做的事情很多,比如说数据分析等,或者是看板功能,甚至使用 ZenHub 结合做到完整的项目管理,另外,跟 @JimmyLv/reading 计划也是可以相互关联和快速追踪的。
利用 GitHub 的 Issue 撰写和梳理卡片。 —— 《卡片大法的神奇之处》
开智部落的小伙伴都知道这种极客的交互方式。我会在一个私有仓库里,把一个 Issue 当作一套卡包,每一个 Issue 下的若干 Comment作为若干卡片。利用这些卡片记录学习或者探讨的问题。GitHub 是一个极客工具,当一个话题探讨结束时,就把这个 Issue 关闭掉。但关闭不代表结束,在关闭之前要整理内容。
这样的好处是保持最小行动。一旦探索结束,立刻整理到 Wiki 中,留下一整条线索和记录。将来要查找资料时,就容易知道东西放在哪。
利用 Issue 的另一个好处是,它的内容是串行的。比如在提交读书卡片时,对于同一本书,不需要去查找更多的地方,在同一个 Issue 下你可以读完所有人与本书相关的读书卡片。而且Issue的方式足够简单,和印象笔记、为知笔记、有道笔记等比起来更加的轻巧方便。抛开形式上的复杂度,使人更加专注在卡片本身的内容上。Github还提供了大量的接口,在积累到一定程度之后可以导出,甚至作图、自然语言处理等,看你想怎么玩了。
#375 所以说,GitHub Issues 本身就是互相双向链接的,而 GitHub 还能做的事情很多,比如说数据分析等,或者是看板功能,甚至使用 ZenHub 结合做到完整的项目管理,另外,跟 @JimmyLv/reading 计划也是可以相互关联和快速追踪的。
利用 GitHub 的 Issue 撰写和梳理卡片。 —— 《卡片大法的神奇之处》
开智部落的小伙伴都知道这种极客的交互方式。我会在一个私有仓库里,把一个 Issue 当作一套卡包,每一个 Issue 下的若干 Comment作为若干卡片。利用这些卡片记录学习或者探讨的问题。GitHub 是一个极客工具,当一个话题探讨结束时,就把这个 Issue 关闭掉。但关闭不代表结束,在关闭之前要整理内容。
这样的好处是保持最小行动。一旦探索结束,立刻整理到 Wiki 中,留下一整条线索和记录。将来要查找资料时,就容易知道东西放在哪。
利用 Issue 的另一个好处是,它的内容是串行的。比如在提交读书卡片时,对于同一本书,不需要去查找更多的地方,在同一个 Issue 下你可以读完所有人与本书相关的读书卡片。而且Issue的方式足够简单,和印象笔记、为知笔记、有道笔记等比起来更加的轻巧方便。抛开形式上的复杂度,使人更加专注在卡片本身的内容上。Github还提供了大量的接口,在积累到一定程度之后可以导出,甚至作图、自然语言处理等,看你想怎么玩了。
《卡片大法的神奇之处》chuansongme.com访问不了,我是zenhub新手,刚刚玩
@FrizzleFur 善用搜索,https://mp.weixin.qq.com/s/t9HcWsnLX7OcY8Wmgc4RoA
https://mp.weixin.qq.com/s/t9HcWsnLX7OcY8Wmgc4RoA
👌,卡片感觉是可以更形象的建立知识网络,更直观些,但管理成本高,如何做到平衡呢?
哈哈哈 使用 Roam Research,不需要平衡。😁 @FrizzleFur Fri