这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 3686 天前的主题，其中的信息可能已经有所发展或是发生改变。
基于Git的Wiki并不是新鲜的主意，就Git Wiki本身而言，也已经有了Gollum项目。这里的重点也不是单项目Git做具备历史版本、本地仓库等特性，而是就大众协同的部分想和大家讨论一下。
我期待的Wiki是一个去中心化的Wiki。比如，现在的Wiki，大家都在同一个公共页面上编辑，这导致了很多争夺、攻击，也带来了大量管理难题，比如锁定、修正、授权等等。
我设想每个人都可以拥有自己独立的Topic，比如，针对一个主题如果我不满意，我可以Clone一个出来，然后基于已有的文本编写我自己觉得好的（不论其是否正确）。可以Push回去，也可以就此保留永久性的差异。
作为读者，他可以对比所有这些不同的版本，或者以作者为中心阅读版本。
而作者可以将一个Fork出来的主题 push给另外一个人要求合并——注意这是并不存在一个传统维基的公共主题页面（public）。对方可以同意也可以拒绝。这之后的思想依然是读者可以跟随、收藏、讨论乃至贡献给自己喜欢的节点。个人对自己的节点有着所有的管理权限。
公共领域依然存在——比如管理者可以根据需要采取对色情内容或者任何内容的封杀——但这里已经属于运营和运营工具的范畴，不属于本文讨论的主要内容。
我期待的Wiki是一个去中心化的Wiki。比如，现在的Wiki，大家都在同一个公共页面上编辑，这导致了很多争夺、攻击，也带来了大量管理难题，比如锁定、修正、授权等等。
我设想每个人都可以拥有自己独立的Topic，比如，针对一个主题如果我不满意，我可以Clone一个出来，然后基于已有的文本编写我自己觉得好的（不论其是否正确）。可以Push回去，也可以就此保留永久性的差异。
作为读者，他可以对比所有这些不同的版本，或者以作者为中心阅读版本。
而作者可以将一个Fork出来的主题 push给另外一个人要求合并——注意这是并不存在一个传统维基的公共主题页面（public）。对方可以同意也可以拒绝。这之后的思想依然是读者可以跟随、收藏、讨论乃至贡献给自己喜欢的节点。个人对自己的节点有着所有的管理权限。
公共领域依然存在——比如管理者可以根据需要采取对色情内容或者任何内容的封杀——但这里已经属于运营和运营工具的范畴，不属于本文讨论的主要内容。
 |
1
dearrrfish 2014-10-22 06:25:50 +08:00
fork的点子很赞，我很喜欢。
但想想将同时带来的恐怖的scaling，和潜在的论坛化。 这个点子更多是运营的范畴，概念和技术反而是次要了。 |
 |
2
Automan 2014-10-22 06:30:37 +08:00
规模是个大问题。
|
 |
3
mingzhi 2014-10-22 09:23:32 +08:00
个人认为:直接改gitlab 就可以实现一个比较弱点的版本.
每个页面都是一个git repo,然后fork 就好了.. |
 |
4
327beckham 2014-10-22 21:43:29 +08:00
为什么不直接用git来管理你的wiki文档就好
|
 |
5
jakwings 2014-10-23 23:42:36 +08:00
用 git 去 clone 一个好多 G 的维基百科真的不好玩，弄出 submodule 也有纠结到底要多少层。总之 git 不是一个理想的工具。建议多去找找最近出现的各种协作式数据库项目。
|
 |
7
Aether OP @327beckham 我在这里想的是协同创造内容这件事，当然95%的用户可能只打算读一读而已。
|
|
8
327beckham 2014-10-24 10:51:00 +08:00
@Aether 恩，我的观点是，git就是用来协同创造内容的，只是这个“内容”可以是代码，也可以是文章
|
|
9
jakwings 2014-10-24 11:38:57 +08:00
@Aether 真的是一篇文章一个 repo 么……感觉太分散了。我觉得把 Wordpress 换个权限系统改造一下都比这个强。clone/fork/push/pull 什么的根本不是重点，如何便民才是最重要的。
|
|
10
Aether OP @jakwings 嗯？我觉得算是一个文件把？也许整个资料库就是一个完整的Repo。除非划分成若干个可以dump offline的部门（比如按照语言来分，或者按照传统的学术领域来分，但感觉没必要）。
|
|
11
Aether OP @327beckham 啊，我同意你的看法啊。我的这个想法也是基于这个想法的。单纯用Git来管理Wiki那么直接用Gollum就好了。不过我这里注重的是协同上的功能。
|
|
12
jakwings 2014-10-25 13:09:51 +08:00
@Aether 唉，感觉你的想法还是太不实际了。其实把维基百科侧边栏的多语种改成多个版本就是你想要的东西了。你都要 push/pull 分两步，又不是同步操作，都不知道你注重个啥。
|
|
13
Aether OP @jakwings 你似乎并不理解我的想法，或者维基百科的运营过程。百科上存在大量的人针对同一个主题反复争夺和修改，乃至于管理员不得不锁帖。或者管理员对于某个人的贡献一言否决的情况。整个过程演变为对公共领域的控制争夺，其实是走到了维基百科当年自己的对立面。我的想法是设想一个解决方法，使得各方面的意见都可以并存。
|
|
19
jakwings 2014-10-28 12:56:17 +08:00
@jakwings s/人/个人/
GitHub 还支持简单的 SVN 功能，可以直接下载个别文件，之后自己修改后打个 patch 就好了。 |
 |
20
jsPop 2014-11-14 20:11:20 +08:00
@Aether 很高兴看到这个去中心化wiki的想法。喜欢。
* 知识本身就是一种无界限的东西，而且很多知识本来就是小群体共享，各自有各自的版本，git来破。 * git管理，天然适合分支与冲突处理。 * 本地服务，速度超然，走到哪用到哪，离线也不断线。 不过用git的话，还需要考虑以repo来根据项目或主题划分信息，否则会出现scaling的问题，并不是每个人都需要到整个知识库。同时，入门门槛偏大，只有懂git的技术狗才喜欢。所以还得考虑做个wrapper，让广大的非技术人员加入，同时也可以用来自动化管理多个repo的sync。话说至此，我觉得其实需要更合适的底层来支撑这种模式，比如说，一上来，本地走一个服务，对什么领域感兴趣，直接跟服务器sync，服务器本身也是一个端，可能跟其它的服务器进行sync，也就是说知识可以是以sharding的形式存在，也可能出现mirror。anyway，目测好像扯远了。 不过很想看到目前git来做，会怎么个玩法。如果要做，喊一声。 |
 |
21
echoflying 2015-06-15 10:35:34 +08:00
顶一个，这个想法有继续探讨吗？
|
Select Language