关于lug.ustc和mirrors.ustc的讨论
Zhang Cheng
- 镜像的热度
- 镜像的相关资讯、链接
- 镜像的同步状态 （已有）
- 服务器本身的全局状态 （已有）
- 大家补充
- 镜像的热度
- tag cloud
- bar chart
- line chart (for trend)
- 其他
- 镜像的相关资讯
- 每个镜像一个网页，内容包括：
- 源的设置帮助
- 相关链接（如官方链接、邮件列表等）
- 相关的podcast、视频collection等
- 新闻动态等
- 其他
- 镜像的同步状态
- 这个现在已经有了，不过脚本可能需要重写一下，网页也可以美化一下，现在的配色太刺眼了
- 服务器的全局状态
- 例如流量、负载等，就用现成的collectd吧
- 镜像的热度
- 后台写脚本分析日志，用rrd保存数据
- 前端用现成的工具，如amcharts等，直接从rrd取数据绘图
- 镜像的相关资讯（这个需要大量的编辑工作）
- 源地设置帮助，这个就不要放到lug的wiki上了，还是独立吧
- 相关链接，这个要靠人力编辑了。可以考虑到各个论坛上找有没有精化帖，直接给链接
- 相关的podcast、视频collection（可以找youku、youtube以及国外许多视频点播网站）
- 新闻动态，这个不好做。可以考虑直接给一个链接到distrowatch等网站
- 镜像同步状态
- 服务器全局状态
- 网站后台形式
- 建议全部用纯静态网站，用jekyll来管理，或者至少用git管理。这样方便大家合作编辑。记得mirrors新机器刚上线时，让大家帮忙写帮助页面，太蛋疼了。用git管理，则可以托管到github、gitcafe等网站，由专人负责merge，服务器定期pull。
- 社团简介（例如介绍精品活动、历史、服务器、项目等）
- Gallery
- 可以按照历次活动来分类
- 也可以增加一些软件show截图的分类，例如桌面show
- Podcast （podcast可以认为是一种视频的feed，许多设备都支持订阅）
-
- 网上收集的相关视频
- 自己活动的录像
- 自己制作的各种教程等录像
- 活动的纪录
- Planet
- 可以认为是所有成员博客的汇总。可以参考各个开源项目的planet，文章都是链接到作者自己的博客的
- 之前lug有一个官方博客，但是要维护一个公共博客太难，大家宁可往自己的博客上写东西。planet就是个非常好的方案。
- 服务器维护的文档、资料（以及其他内部资料）
- 建议整站是用纯静态的方式，例如用jekyll，用git管理。好处前面已述。
- 社团简介、Gallery、Podcast分别是Pages
- 成员可以在lug.ustc上放自己的博客，但只接受静态博客，推荐jekyll。使用三级子域名
- 活动的纪录也可以认为是一个单独的“个人博客”，或者也可以由任何一个人发表在自己的个人博客上，而通过某种方式汇总到主页上
- 内部资料，这个就开wiki吧，非公开wiki。对于方便公开出去的技术资料，鼓励大家在博客上分享。
Bojie Li
这段时间可以先讨论lug.ustc，用git＋jekyll管理的优点张成已经说过。有一个小问题：编辑者不能实时在lug.ustc上看到自己的改动（需要专人merge，即使开放push权限也要等待定时pull），虽然jekyll可以在本地预览，但编辑者会不会有些心慌？
planet到时可以链接到blog.ustc（面向校内师生的Wordpress服务）或者lug.ustc上的静态博客。
Gallery用什么展示形式或者工具比较合适？LUG博客上的图片滚动显示有个体验问题，用户不能控制图片的翻页，经常是一张图片没看清就翻到下一张了。
On 10/10/12, Zhang Cheng <steph...@gmail.com> wrote:
> 新开一个主题讨论吧。我来抛个砖。
> 大家讨论时，希望多讨论展现的内容、形式，而不是实现的技术。技术永远都不是难点。而且实际上许多事情都有现成的东西可以用，不用自己开发，成本很小。
>
> *mirrors.ustc.edu.cn*
>
> 在mirrors.ustc.edu.cn上可以展示的内容：
>
> - 镜像的热度
> - 镜像的相关资讯、链接
> - 镜像的同步状态 （已有）
> - 服务器本身的全局状态 （已有）
> - 大家补充
>
> 考虑的展现形式：
>
> - 镜像的热度
> -
> - tag cloud
> - bar chart
> - line chart (for trend)
> - 其他
> - 镜像的相关资讯
> -
> - 每个镜像一个网页，内容包括：
> - 源的设置帮助
> - 相关链接（如官方链接、邮件列表等）
> - 相关的podcast、视频collection等
> - 新闻动态等
> - 其他
> - 镜像的同步状态
> -
> - 这个现在已经有了，不过脚本可能需要重写一下，网页也可以美化一下，现在的配色太刺眼了
> - 服务器的全局状态
> -
> - 例如流量、负载等，就用现成的collectd吧
>
>
> 简述技术方案：
>
> - 镜像的热度
> -
> - 后台写脚本分析日志，用rrd保存数据
> - 前端用现成的工具，如amcharts <http://www.amcharts.com/>等，直接从rrd取数据绘图
> - 镜像的相关资讯（这个需要大量的编辑工作）
> -
> - 源地设置帮助，这个就不要放到lug的wiki上了，还是独立吧
> - 相关链接，这个要靠人力编辑了。可以考虑到各个论坛上找有没有精化帖，直接给链接
> - 相关的podcast、视频collection（可以找youku、youtube以及国外许多视频点播网站）
> - 新闻动态，这个不好做。可以考虑直接给一个链接到distrowatch等网站
> - 镜像同步状态
> - 服务器全局状态
> - 网站后台形式
> -
> -
>
> 建议全部用纯静态网站，用jekyll来管理，或者至少用git管理。这样方便大家合作编辑。记得mirrors新机器刚上线时，让大家帮忙写帮助页面，太蛋疼了。用git管理，则可以托管到github、gitcafe等网站，由专人负责merge，服务器定期pull。
>
>
> *lug.ustc.edu.cn*
>
> 网站上需要的内容：
>
> - 社团简介（例如介绍精品活动、历史、服务器、项目等）
> - Gallery
> -
> - 可以按照历次活动来分类
> - 也可以增加一些软件show截图的分类，例如桌面show
> - Podcast （podcast可以认为是一种视频的feed，许多设备都支持订阅）
> -
> - 网上收集的相关视频
> - 自己活动的录像
> - 自己制作的各种教程等录像
> - 活动的纪录
> - Planet
> -
> - 可以认为是所有成员博客的汇总。可以参考各个开源项目的planet，文章都是链接到作者自己的博客的
> - 之前lug有一个官方博客，但是要维护一个公共博客太难，大家宁可往自己的博客上写东西。planet就是个非常好的方案。
> - 服务器维护的文档、资料（以及其他内部资料）
>
>
> 呈现及实施方式简述
>
> - 建议整站是用纯静态的方式，例如用jekyll，用git管理。好处前面已述。
> - 社团简介、Gallery、Podcast分别是Pages
> - 成员可以在lug.ustc上放自己的博客，但只接受静态博客，推荐jekyll。使用三级子域名
> - 活动的纪录也可以认为是一个单独的“个人博客”，或者也可以由任何一个人发表在自己的个人博客上，而通过某种方式汇总到主页上
> - 内部资料，这个就开wiki吧，非公开wiki。对于方便公开出去的技术资料，鼓励大家在博客上分享。
>
>
>
> --
> Cheng,
> Best Regards
>
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
>
Bojie Li
@喵喵 这个任务量是不是有些大？
Zhang Cheng
我觉得挺完善的了，技术复杂度也不高。mirrors相关的可以到新服务器分下来再做，有了新机器，一切从头开始，大家喜新厌旧的热情也更容易发挥。mirrors维护小组可以先调研下rrd和amcharts。
这段时间可以先讨论lug.ustc，用git＋jekyll管理的优点张成已经说过。有一个小问题：编辑者不能实时在lug.ustc上看到自己的改动（需要专人merge，即使开放push权限也要等待定时pull），虽然jekyll可以在本地预览，但编辑者会不会有些心慌？
planet到时可以链接到blog.ustc（面向校内师生的Wordpress服务）或者lug.ustc上的静态博客。
Gallery用什么展示形式或者工具比较合适？LUG博客上的图片滚动显示有个体验问题，用户不能控制图片的翻页，经常是一张图片没看清就翻到下一张了。
Bojie Li
own dog food）。
2、第三方Gallary服务求推荐。
Miaomiao Li
Bojie Li
Miaomiao Li
Bojie Li
Miaomiao Li
Bojie Li
Bojie Li
Zhang Cheng
我也很担心LUG服务器维护小组的传承问题，现在主要负责技术的tux要像张成那样经常在列表里冒泡该多好啊……看着服务器维护小组现有成员一个个毕业了或者忙起其他事情来，新人却没有接上，而且因为我是大三的调动不了更高年级的，这是一件很头疼的事。
Yuanchong Zhu
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
--
灿烂星空，你就是我的英雄！
Zhang Cheng
Yuanchong Zhu
Zhang Cheng
Bojie Li
我听说过一个说法，开发者用的开源项目最好不要设计GUI（图形用户界面），因为这东西需要投入很多精力来开发和维护，而开源组织本身就没有那么多的人力和组织强制力，把宝贵的时间浪费在GUI而非核心功能上不值得。
On 10/11/12, Zhang Cheng <steph...@gmail.com> wrote:
Bojie Li
lab，LUG的每个其他实验项目可以开一台虚拟机，这样不同服务之间的隔离就比较充分了，给权限时也就不用缩手缩脚了，能给新人更多的实战经验。
其实科大学生接触服务器的渠道一个是自购VPS（上面一般只是个人博客等），一个是学院、实验室的服务器，有经验的是少数。要求服务器维护小组成员拥有经验固然无可厚非，但这影响了成员来源的基数。LUG
lab可以解决新人的锻炼问题，配置文件脚本化和版本控制可以降低维护者的门槛。
事实上jameszhang还让我们调研OpenStack，如果能琢磨明白，还可以分一台物理服务器面向LUG成员提供VPS服务，这样就更爽了。
On 10/11/12, Zhang Cheng <steph...@gmail.com> wrote:
Xilin Sun
2012/10/11 Zhang Cheng <steph...@gmail.com>:
> 我怕老机器性能可能不够。。。而且我希望副站也放在网络中心，网络资源好一些。老机器网络中心放不了。
>
> 哦，说到老机器，我试试根deepin联系，看看能不能让他们赞助一些老机器给我们用，性能会比我们的老debian好一些，跟老oss（也就是现在的lug）差不多，放在活动室里。
--
May the source be with you.
孙锡麟，SUN Xilin, undergraduate student at HKPolyU
Zhang Cheng
Yan Wang
2012/10/11 Bojie Li <boj...@gmail.com>
我觉得挺完善的了，技术复杂度也不高。mirrors相关的可以到新服务器分下来再做，有了新机器，一切从头开始，大家喜新厌旧的热情也更容易发挥。mirrors维护小组可以先调研下rrd和amcharts。
这段时间可以先讨论lug.ustc，用git＋jekyll管理的优点张成已经说过。有一个小问题：编辑者不能实时在lug.ustc上看到自己的改动（需要专人merge，即使开放push权限也要等待定时pull），虽然jekyll可以在本地预览，但编辑者会不会有些心慌？
Zhang Cheng
如果开放push权限的话似乎可以用git hook来解决立马pull的问题？参考：http://crosbymichael.com/how-to-manage-your-website-with-git.html
Yan Wang
I see! 理解了! 我们公司内部也是这样处理的，每周二有专门的组来审核，merge，push到生产环境里。但有两套独立的系统，intern系统是开放push权限，每个人都可以push，然后立马能看结果，生产环境是需要审核的。也许我们也可以这样做？
Best Regards,
Yan
--Cheng,Best Regards
Bojie Li
> 如果开放push权限的话似乎可以用git
> hook来解决立马pull的问题？参考：http://crosbymichael.com/how-to-manage-your-website-with-git.html
我们的仓库不是要托管在github或者gitcafe上吗？github/gitcafe上能写git
hook吗？当然如果origin版本库是在LUG的服务器上就无所谓了。
Bojie Li
request，然后再由专人merge到生产环境（mirrors）去。
但有个问题：已经放到mirrors里的源的脚本如果要修改，如何测试？不经测试就发出pull
request，全看merge那个人的眼力？软件源不同于网站，同步一遍要费很多时间和硬盘空间。
2012/10/11 Yan Wang <gra...@gmail.com>:
Zhang Cheng
我们的仓库不是要托管在github或者gitcafe上吗？github/gitcafe上能写git
hook吗？当然如果origin版本库是在LUG的服务器上就无所谓了。
github上可以设置hook。我们当然也需要在内部服务器上部署一个仓库。
Zhang Cheng
但有个问题：已经放到mirrors里的源的脚本如果要修改，如何测试？不经测试就发出pull
request，全看merge那个人的眼力？软件源不同于网站，同步一遍要费很多时间和硬盘空间。
修改已有的脚本的需求很少，即使修改，一般也只是修改一个upstream的地址，出错的概率非常小，可以直接push上去。
Bojie Li
> ps，你这个说法“如果origin版本库是在LUG的服务器上”是不对的。origin是一个remote的名字，只是名字特殊（git
> push时默认的remote），但对于git push $REMOTE来说，没有什么区别。git仓库，从git本身来说没有地位上的差别。
有人设置两个不同的remote，一会儿push到origin，一会儿push到origin1吗？
Zhang Cheng
> ps，你这个说法“如果origin版本库是在LUG的服务器上”是不对的。origin是一个remote的名字，只是名字特殊（git有人设置两个不同的remote，一会儿push到origin，一会儿push到origin1吗？
> push时默认的remote），但对于git push $REMOTE来说，没有什么区别。git仓库，从git本身来说没有地位上的差别。
Bojie Li
> 1、以某一个人的仓库作为正式发布版或者其他等价的含义。只有一个人可以向这个仓库push。所有人像这个人提交patch（就是commit的集合，在github上面用pull
> request的方式提交）。这个人负责审核，merge，并push到主仓库中。这个在开源社区很常见，linux就是这样。Linus这个人的仓库，目前就是Linux的官方仓库。
>
> 2、若干个人都可以向同一个仓库push内容。这可能更适合于企业内部的操作模式，因为这要求具有push权限的人都是可信的，并且都能对仓库代码的完整性负责。例如，你不能坑跌的push一个补丁上去之后导致线上的代码编译不过了。
对我们来说，lab用第2种模式，mirrors用第1种模式，是不是就行了？
第2种模式在成员水平参差不齐的情况下确实容易出问题。有一个人自己的机器上没配好开发环境，就开始重复这样的循环：写一点代码=>commit=>push=>看看网站是否正常运行了=>如果有问题，继续改代码。我一直不知道他是这么干的，直到他向我抱怨在服务器上不敢用var_dump把变量打印出来。与其这样，还不如给一个SSH帐号，直接到Web目录里去修改。
Zhang Cheng
Bojie Li
另外，你多点备份的目的是不是怕服务器跟你的电脑同时挂掉？为什么不push到origin1，在origin1上写个post-update脚本自动push到origin2上？
On 10/11/12, Zhang Cheng <steph...@gmail.com> wrote:
Bojie Li
另外，关于分支，采用下面的方法是否合理？每个人建一个私人分支，开发新功能的时候就在私人分支上开发，调试得差不多后就merge到master上；修复bug之类的直接在master上进行。
顺便再问个问题，开发程序的时候真的要像软件工程的书里写的那样，做单元测试、模块测试、回归测试，还有什么敏捷、测试驱动开发吗？拿网站来说，在浏览器里动手试一下，各种功能都能用不就行了？
我没有开发过真正项目，求经验。
On 10/11/12, Zhang Cheng <steph...@gmail.com> wrote:
Zhang Cheng
如何在push的时候自动push到多个remote？有没有在git框架内（即不使用bash脚本）解决的办法？
另外，你多点备份的目的是不是怕服务器跟你的电脑同时挂掉？为什么不push到origin1，在origin1上写个post-update脚本自动push到origin2上？
我平时设置多个remote，多点备份是原因之一，但也有其他原因。例如，我有一些项目放在github上，可能会经常在多台电脑上做。白天在公司的电脑，晚上回家在家里的电脑。白天做了一半，不想把不完整的代码commit/push到github上面，我就直接push到我自己的另外一台服务器上，回家后从那个服务器pull下来。当完成一个功能后，再一次性push到github上。这只是一个是用场景。有些时候，我的项目也会有不同的分支，我会把不同的分支push到不同的remote里。
Zhang Cheng
既然是同一个项目，为什么不在同一个repo里工作？如果需要并行开发功能的话开多个分支就行了啊。是为了方便权限控制吗？
另外，关于分支，采用下面的方法是否合理？每个人建一个私人分支，开发新功能的时候就在私人分支上开发，调试得差不多后就merge到master上；修复bug之类的直接在master上进行。
顺便再问个问题，开发程序的时候真的要像软件工程的书里写的那样，做单元测试、模块测试、回归测试，还有什么敏捷、测试驱动开发吗？拿网站来说，在浏览器里动手试一下，各种功能都能用不就行了？
Chao Gao
工程大了测试就没那么简单了，要考虑各种情况。
Bojie Li
还有一个问题：不论是建多个repo还是多个分支，都要merge，其中很可能出现冲突。我们项目不大，都是单master分支，几个人都往里push，还会出现conflict；如果merge的时间间隔变长，一次merge可能出现很多冲突，另外我也无法知道其他人的开发进度，这本来是用git的一大优点啊。
Zhang Cheng
这样是否合适：在服务器上给每个人建一个repo，再建一个发布repo，每个人在自己的repo里想怎么搞怎么搞；模块开发完成后由项目负责人或者开发者自己把修改merge到发布repo里。不过这样做跟每人建一个分支有多大区别？每个人需要在自己的repo里建立很多分支吗？
还有一个问题：不论是建多个repo还是多个分支，都要merge，其中很可能出现冲突。我们项目不大，都是单master分支，几个人都往里push，还会出现conflict；如果merge的时间间隔变长，一次merge可能出现很多冲突，另外我也无法知道其他人的开发进度，这本来是用git的一大优点啊。
Yan Wang
非常赞同。根据个人的经验，git的确是这样使用的。
[OT] 有没有可能把邮件列表的内容搞成一个Wiki, 这样大家可以编辑里面的内容并且vote有价值的帖子，相当于reddit和wiki的合体。这样的产品如果能做出来的话会有利于大家合作整理知识，也非常有意思。
Best Regards,
Yan
Bojie Li
> [OT] 有没有可能把邮件列表的内容搞成一个Wiki,
> 这样大家可以编辑里面的内容并且vote有价值的帖子，相当于reddit和wiki的合体。这样的产品如果能做出来的话会有利于大家合作整理知识，也非常有意思。
首先是技术问题。Groups的邮件可以从Web抓取，用正则表达式分析旧版groups的HTML（新版groups是ajax的，我没分析明白）。当然如果有本group元老级的人愿意把所有邮件SMTP取下来打个包，就不用我们费时间写爬虫了。Google有防机器人机制，如果写个爬虫持续抓取会被封IP（至少搜索功能是这样的）。当然可以在脚本里加上一定的延迟，但这样抓取时间就长了。
然后是非技术问题。每个thread作为一个词条？每个post作为词条内的一个section？然后大家就可以把thread中的回复进行整理，做成一篇可以看的文章？这样做的目的是什么？为什么不让大家到groups的Web页面直接去看、搜索？
Zhang Cheng
[OT] 有没有可能把邮件列表的内容搞成一个Wiki, 这样大家可以编辑里面的内容并且vote有价值的帖子，相当于reddit和wiki的合体。这样的产品如果能做出来的话会有利于大家合作整理知识，也非常有意思。
Bojie Li
> 2012/10/12 Yan Wang <gra...@gmail.com>
>>
>> [OT] 有没有可能把邮件列表的内容搞成一个Wiki,
>> 这样大家可以编辑里面的内容并且vote有价值的帖子，相当于reddit和wiki的合体。这样的产品如果能做出来的话会有利于大家合作整理知识，也非常有意思。
>
> stackoverflow差不多就是这样的一个东西吧？
我觉得把邮件列表存档增加一个vote功能，做成stackoverflow没什么意思吧。Yan
Wang想的是不是把邮件列表的优秀内容分类整理到wiki里，做成一个知识库？如果是建立知识库的目的，我觉得数据源应该不限于邮件列表，而且自动生成的效果一般不好（想想国内的各种采集站吧），还是人工整理比较靠谱。
Yan Wang
2012/10/12 Bojie Li <boj...@gmail.com>
Bojie Li
> 2012/10/12 Bojie Li <boj...@gmail.com>
>> Wang想的是不是把邮件列表的优秀内容分类整理到wiki里，做成一个知识库？如果是建立知识库的目的，我觉得数据源应该不限于邮件列表，而且自动生成的效果一般不好（想想国内的各种采集站吧），还是人工整理比较靠谱。
>
>
> 是的是的，我的意思就是人工整理，在邮件列表的基础上提供人工整理知识库等等功能。
> （我还在试图把这个想法整理的更具系统性然后发上来。之前就有相关的思考，也和9911, 0000的师兄讨论过，觉得甚至是一个有意思的创业的题目）
我觉得一个以内容为主的网站要有价值，
如果内容非原创，就要有足够大的数据源和足够好的自动分类/检索/推荐算法，比如Google、社会化推荐网站；
如果内容是原创UGC，则要提供足够简单的用户参与方式，论坛、wiki、delicious、instagram都是好的例子；
如果内容多为站务人员原创，如门户网站，则需要足够大的内容编辑团队，这个可以基本排除。
人工整理知识库主要存在一个冷启动问题，很少有人愿意在没有回报、看不到前景的情况下投入经历去编写wiki。暑假前启动了个校园百科项目，现在还没动静。
Bojie Li
linux版上的精华帖子。
其实我觉得这样的FAQ对熟练使用linux的人来说可能没必要（Google不就行了？Archwiki也是很好的信息源），但新手往往对linux的基本知识不甚了解，也看不懂英文技术资料，网上查到的中文资料质量参差不齐（大多是博客，只适用作者的特定情况），可能使新手更加迷惑。
我希望有这样一个给新手准备的中文wiki，包括linux基本知识，linux安装指南，基本linux命令，文件系统简介，常见启动问题、驱动问题、分区问题的解决等。事实上就是LUG历次面向新手的活动内容的合集。
有人会说，这些东西鸟哥上都有啊，但不是每个人都有耐心和时间把厚厚的一本《鸟哥》看完。正如编程语言需要Documentation（Reference），又需要Tutorial一样，我们不可能每拿到一门新语言就一头钻进库函数的细节里。
我还设想过录视频的形式会不会更直观，不过感觉我没有耐心看完几分钟的教学视频，文字＋截图的教学材料看得更快，不知道大家是什么感觉。
最后谈这个FAQ计划的可行性。作为对比的校园百科，是我最早在本邮件列表看到，上学期跟团委网络工作办公室提的，校友总会的老师认可这样的百科能对宣传科大校园文化起到很好的效果，同学们也认为它能方便校园信息的查询，但真正做起来，总要有个初始内容积累吧，编辑任务分配下去就没人做了（当然也可能是因为此组织成员对百科项目的认同感不足）。
linux-FAQ从内容数量上看，与校园百科差不多；但从可能参与编辑的用户基数上说，就比校园百科大多了。从初始内容积累的难易程度上看，LUG人帮助linux新手的热情，比科大人整理校园信息的热情，平均意义上是更大的。从项目的意义或者发展前景来看，一个是校园，一个是中文开源社区，参与者的动力也可能更大。
Yan Wang
Nodnod, 如果对这样的话题感兴趣的话，不妨先讨论一下为什么要这样做，好处是什么，然后再看如何去实现。
我的想法是在使用这个邮件列表参与讨论的过程中，学到了很多东西，有很多启发。但也遇到了一些不便：
- 一些觉得很喜欢的东西不方便存档保存。虽然可以手动拷贝，gmail加星，evernote存档，但是：
- 一方面这都依赖于一些通用的知识管理工具，事后搜索的时候因为很多知识都混杂在一起所以会不方便（这一点不是很确定，因为我没有实际去用evernote整理一份这样的“精华区”出来）。
- 另一方面这样只有一个人在整理，缺乏质量上的保证，比较低效，同时往往也丧失了更多的讨论的机会。
- 讨论的时候实际上形成了一个话题树，但gmail或者group是根据时间顺序线性展示的。这就会造成浏览的时候非常低效：
- 整个group都很精彩，所以我有动力把全部回复看完，但很多时候别人讨论的东西和我的领域又不相关，只能一个一个浏览，找到精彩的再细读。如果能把这个树状的结构直接可视化出来，辅以关键字会不会好一些？
- 没有引入用户对邮件的评价体系。如果有这样评价体系的话，即使有些发言和我的领域不直接相关，但大家都觉得它很棒，这样的帖子也不会被错过。
- 邮件的质量相对受限。比如某封邮件很精彩但是有错别字，别人就无法修改。或者一个观点很新颖但缺乏论据支持，另一封邮件提供了佐证，没办法整合起来形成一个完整的以后能直接拿来用的论述。
- 知识库：提供一个wiki页面的集合，和方便的“整合邮件进知识库”的功能。在浏览界面上就可以把一个指定的邮件整合进一个指定的知识库的页面（当然需要人工编辑）。
- 讨论的可视化：向前面说的那样，引入树状的浏览模式，辅以关键字提取来帮助甄别有价值的讨论。同时引入用户的评价体系。
Best Regards,
Yan
Bojie Li
我觉得要自己搞一个这种服务的话，如何与Gmail整合是个问题（如何把指定的邮件整合进知识库），而且要看看Google
Groups的用户协议是否允许这种行为，毕竟没有提供公开API。
On 10/13/12, Yan Wang <gra...@gmail.com> wrote:
> Nodnod, 如果对这样的话题感兴趣的话，不妨先讨论一下为什么要这样做，好处是什么，然后再看如何去实现。
>
> 我的想法是在使用这个邮件列表参与讨论的过程中，学到了很多东西，有很多启发。但也遇到了一些不便：
>
>
> - *一些觉得很喜欢的东西不方便存档保存。*虽然可以手动拷贝，gmail加星，evernote存档，但是：
> -
>
> 一方面这都依赖于一些通用的知识管理工具，事后搜索的时候因为很多知识都混杂在一起所以会不方便（这一点不是很确定，因为我没有实际去用evernote整理一份这样的“精华区”出来）。
> - 另一方面这样只有一个人在整理，缺乏质量上的保证，比较低效，同时往往也丧失了更多的讨论的机会。
> - 讨论的时候实际上形成了一个话题树，但*gmail或者group是根据时间顺序线性展示的*。这就会造成浏览的时候非常低效：
> -
>
> 整个group都很精彩，所以我有动力把全部回复看完，但很多时候别人讨论的东西和我的领域又不相关，只能一个一个浏览，找到精彩的再细读。如果能把这个树状的结构直接可视化出来，辅以关键字会不会好一些？
> - 没有引入用户对邮件的评价体系。如果有这样评价体系的话，即使有些发言和我的领域不直接相关，但大家都觉得它很棒，这样的帖子也不会被错过。
> - *邮件的质量相对受限*
>
> 。比如某封邮件很精彩但是有错别字，别人就无法修改。或者一个观点很新颖但缺乏论据支持，另一封邮件提供了佐证，没办法整合起来形成一个完整的以后能直接拿来用的论述。
>
> 所以这里提出的解决方法是：
>
> -
>
> 知识库：提供一个wiki页面的集合，和方便的“整合邮件进知识库”的功能。在浏览界面上就可以把一个指定的邮件整合进一个指定的知识库的页面（当然需要人工编辑）。
> - 讨论的可视化：向前面说的那样，引入树状的浏览模式，辅以关键字提取来帮助甄别有价值的讨论。同时引入用户的评价体系。
Yan Wang
如果是从实现的角度来说的话有很多种途径，比如可以做一个自己的平台（然后里面放一个mailman之类的东西，相当于做一个mailman的新颖实用的Web界面），可以向其他平台提供接口等等，或者甚至做成一个像Disqus那样的插件。
Bojie Li
Gmail插件，操作起来确实比Web版Gmail舒服（充分利用了宽屏，左侧主题列表，右侧邮件内容），不过我还是在用原汁原味的Gmail。
Gmail的主题模式是个很赞的东西，技术上也不难实现，但其他邮件服务为什么不用？有哪个国内的邮件服务是提供主题模式的？这点是我一直想不明白的。
Zhang Cheng
你是想做个Web版邮件客户端？我见过一个Chrome
Gmail插件，操作起来确实比Web版Gmail舒服（充分利用了宽屏，左侧主题列表，右侧邮件内容），不过我还是在用原汁原味的Gmail。
Gmail的主题模式是个很赞的东西，技术上也不难实现，但其他邮件服务为什么不用？有哪个国内的邮件服务是提供主题模式的？这点是我一直想不明白的。
Yan Wang
抱歉之前没有强调清楚，我的意思不是做一个邮件客户端，而是做一个讨论的工具，提供两个feature:
1) 方便阅读的可视化，比如树状结构，自动关键字提取等。
2) 方便的知识提取和总结。
至于是Web界面还是邮件列表形式不是太关键。这可以是一个类似论坛或者reddit的东西，但要有上面的两个feature。也可以是一个邮件列表的形式，提供有上面两种feature的客户端或者chrome插件。甚至是其他各种形式。
我困惑也很感兴趣的地方是这样的想法究竟有没有去做的价值。欢迎拍砖！
Bojie Li
Zhang Cheng
抱歉之前没有强调清楚，我的意思不是做一个邮件客户端，而是做一个讨论的工具，提供两个feature:
1) 方便阅读的可视化，比如树状结构，自动关键字提取等。
2) 方便的知识提取和总结。至于是Web界面还是邮件列表形式不是太关键。这可以是一个类似论坛或者reddit的东西，但要有上面的两个feature。也可以是一个邮件列表的形式，提供有上面两种feature的客户端或者chrome插件。甚至是其他各种形式。
我困惑也很感兴趣的地方是这样的想法究竟有没有去做的价值。欢迎拍砖！
我大概理解你的意思。
Bojie Li
Data，StackOverflow、Quora、Reddit这类社会化问答网站用的是用户评价，Google
Reader会考虑用户的偏好，Facebook的状态排序会考虑发布者的影响力。其实说到底，信息的筛选、排序、推荐都是IR（Information
Retrieval）的事情，我不是专业人士也不好多说。
Zhang Cheng
最后谈这个FAQ计划的可行性。作为对比的校园百科，是我最早在本邮件列表看到，上学期跟团委网络工作办公室提的，校友总会的老师认可这样的百科能对宣传科大校园文化起到很好的效果，同学们也认为它能方便校园信息的查询，但真正做起来，总要有个初始内容积累吧，编辑任务分配下去就没人做了（当然也可能是因为此组织成员对百科项目的认同感不足）。
至少，我觉得 百科 这种形式并不是很适合LinuxFAQ。lug.ustc上的wiki已经有好几年了，到现在也没有多少数据。我觉得大家不写的原因不是不愿意写，有时候可能是因为不知道如何组织内容，想写点东西，但是提笔之后发现怎么写都不合适，纠结半天之后就放弃了。
Bojie Li
On 10/13/12, Zhang Cheng <steph...@gmail.com> wrote:
Bojie Li
“写书情结”有关，我喜欢把一个很大的话题自顶向下地分成若干章节，再一点点地填充进去。话说回来，这种形式反而适合个人写作，不适合群体协作了，因为每个人都对知识架构的组织形式有自己的见解。
维基百科的词条之间是松散关系，只有这种松散关系才能让所有编辑者能够快速上手做出贡献，这对依靠UGC的百科来说很重要。如果wiki的编辑者首先要熟悉整个wiki的知识架构，编写词条像报bug一样谨小慎微，百科就很难火起来。
On 10/13/12, Zhang Cheng <steph...@gmail.com> wrote:
Yan Wang
是这个意思，不一定要形成一个云，但要能提示下面的讨论和其他分支不同的地方。
Yan Wang
我大概理解你的意思。
先说价值。你觉得有多少用户需要这样的工具？或者target用户是谁？有多少人需要这样的工具？
我有个简单地想法，这样一个工具，它可以（假设内容就是邮件列表）：1、对于一个主题，可以灵活的切换这几种排序方式：按时间顺序、按群众vote排序、按自己关心的关键字/关键作者等排序（或者说按自定义的质量计算函数算出来的质量排序）2、对于所有主题，可以用关键字搜索，并且对搜索结果可以方便的按上述几种方式排序。你看这样的工具能否满足你的需求？
2) 没有把零散的邮件讨论聚集成可以重复查询里用的知识库的功能。
我觉得，邮件列表相比wiki的优点是，在邮件列表里，内容是由讨论产生的，会记录下整个产生的过程，这个过程，对于将来再次阅读时，可能也具有启发作用。而wiki里则往往只有一个结论，即结果，没有内容产生的过程。而邮件列表相比wiki的缺点是，噪音太大，当仅仅想要查找结果时，比较困难。
而我感觉，“查找”这件事情，最重要的是排序。Google做了这么多年的搜索，搜索技术的核心难点仍然是如何对结果排序（而不是其他如如何索引大规模数据、如果分布式查找等）。排序是对内容组织的一种方式，排序的目的是把用户最需要的内容找出来。
所以，我感觉，如何组织内容，根本的问题也是如何对内容进行（自动化的）最优排序。
--Cheng,Best Regards
Bojie Li
这个提取出来的标签是以主题为单位，还是帖子为单位？显示在什么地方？
Bojie Li
你设想的这个工具确实是能用来办正事的，而且在设置筛选排序规则等方面可能有一些“经验”，我觉得采用ifttt的模式能让更多人用好这个工具，提供一些基本元素（trigger，action）和组合方式（recipe），可以使用别人共享出来的比较火的recipe，也可以自己创建recipe。
On 10/13/12, Yan Wang <gra...@gmail.com> wrote:
Yan Wang
好吧，我表示不能理解……一个帖子下面的讨论会分成几个分支？每个回复及其回复树就构成一个分支吗？
这个提取出来的标签是以主题为单位，还是帖子为单位？显示在什么地方？
Bojie Li
凡是自然语言处理的程序都涉及一个同义词近义词合并的问题，例如搜“中国科大”要检索出“中国科学技术大学”，要做好query
expansion，或者是人工维护受控词表，或者是从大规模语料库中统计提取，或者从用户点击数据中挖掘。帖子的聚类的质量依赖于帖子内词语的分类质量，例如计算机应该能判断（git，版本控制），（git，wiki），（git，mirrors）哪组更亲近。这个东西我觉得LUG这样的兴趣小组没有时间与能力完成，如果作为创业项目或者实验室的科研项目还有可能。
Yan Wang
哦哦~~抱歉，我一直不在说如何实现的问题，是想和大家探讨一下这样的东西是不是有意义，抱歉之前没有说清楚。至于实现，因为我就是属于一个科研小组的，周围也有其他团队比如Michael Collins（阿波罗11号指令舱里面的宇航员(误)），所以这个是可以做到的~谢谢你的意见！
Bojie Li
Bojie Li
今天我跟喵喵讨论了一下，他比较忙，我帮忙把初步的想法发上来，欢迎拍砖。
LUG“网站群”包括：
- mirrors
- Software Store
- LUG社团主页
- 知识库
- blog.ustc
- 设计同一套CSS
- 可以使用jekyll维护，对我们开发者来说使用自己的编辑器比wiki的textarea编辑更舒服。但要看看jekyll的学习曲线会不会太陡峭。
- 喵喵打算等有时间的时候，给jekyll设计若干CSS模板，这样就不像纯粹bootstrap那样单调了。（这与网站群的事情无关）
- 待讨论：是否可以搞一个类似Google的硬又黑导航条，作为LUG网站群的统一导航？主要是mirrors，这个导航条会不会让人认为mirrors从属于LUG？mirrors与LUG应该是什么关系？
- 为保持与lftp等工具的兼容，在directory listing中javascript跳转到Web首页
- mirrors首页采用自适应的宽屏设计
- 首页左侧显示若干发行版图标
- 图标按照热度调整顺序，这个可以人工定期来做
- 点击每个图标，在首页主内容区ajax显示：
- 发行版的简要介绍
- 大按钮Get Latest Version（下载ISO）
- 大按钮Help（链接到帮助）
- 软件包搜索框（software store）
- 首页主内容区，默认为一些mirrors简介，点击发行版图标后被覆盖
- 首页右边栏：
- 新闻动态，发行版新版本的发布信息。mirrors上适合放这种有点UGC性质的信息吗？
- Mirrors Lab
- 发行版趋势概览
- 关于我们（链接）
- 捐赠（链接）
- 镜像同步状态页面加上CSS
- 发行版趋势页面，比概览更丰富的统计指标，用张成说的日志分析和自动画图
- 能否根据浏览器的语言来显示不同语言（中文、英文）？
- 是否使用jquery？
- 几十K的jquery是否会消耗过大的带宽，或减缓页面加载速度？
- 需要统计一下浏览器访问量占mirrors总访问量的比重
- 社团主页包括以下内容：
- LUG简介
- LUG活动（每个活动一个页面）
- Gallery（按照活动来打tag）
- Podcast（按照活动来打tag）
- Planet（LUG会员博客链接）
- 内部文档资料
- jekyll可以分category，上面各项可以作为category
- jekyll可以加tag，LUG的每个活动可以作为一个tag
- 由于是静态编辑，git上传，添加图片之类的也就不太蛋疼了，用相对路径即可
- 建立一个知识库，主要包括三部分：
- Tutorial
- FAQ
- Tips
- 待讨论：知识库用什么形式？
- wiki？
- blog？
- jekyll？
- stackoverflow？
- 喵喵认为FAQ和tips用blog的形式更合适，通过搜索来查找。大家认为呢？
- 知识库中的交叉引用是很重要的，一定要方便在一个条目中引用另一个条目，不能出现孤立条目。
- 能否自动进行交叉引用？例如在文章中找出所有与词条名称匹配的字符串，并加上交叉引用链接。当然有一些特别常见的词条名称可能导致过多的链接，需要有个“停用词表”。
- 知识库中的信息从哪里来？
- Tutorial
- 鸟哥
- 论坛上的linux入门方面的精华帖
- FAQ
- 从archlinux中文wiki抓取，并在其基础上演绎（Archwiki是GNU FDL协议，抓过来注明出处并在其基础上演绎是否允许？）
- linux版上的精华帖
- linux邮件列表上的精华帖
- 我们自己发现的问题及解决方案
- Tips
- 开源资讯类站点
- 我们自己分享的Tips
- 用户如何参与知识库的构建？
- 直接编辑知识库
- 做一个javascript浏览器插件，将看到的好网页提交上去，供我们参考
- FAQ问题提交表单
Zhang Cheng
谢谢你的建议。这个可以部分满足需求，但是对于下面两点需求无法满足：1) 没有体现讨论的分支结构，最好加一个树状visulaization的功能。
2) 没有把零散的邮件讨论聚集成可以重复查询里用的知识库的功能。
Zhang Cheng
- 为保持与lftp等工具的兼容，在directory listing中javascript跳转到Web首页
- mirrors首页采用自适应的宽屏设计
- 首页左侧显示若干发行版图标
- 图标按照热度调整顺序，这个可以人工定期来做
- 点击每个图标，在首页主内容区ajax显示：
- 发行版的简要介绍
- 大按钮Get Latest Version（下载ISO）
- 大按钮Help（链接到帮助）
- 软件包搜索框（software store）
- 首页主内容区，默认为一些mirrors简介，点击发行版图标后被覆盖
- 首页右边栏：
- 新闻动态，发行版新版本的发布信息。mirrors上适合放这种有点UGC性质的信息吗？
- Mirrors Lab
- 发行版趋势概览
- 关于我们（链接）
- 捐赠（链接）
- 镜像同步状态页面加上CSS
- 发行版趋势页面，比概览更丰富的统计指标，用张成说的日志分析和自动画图
- 能否根据浏览器的语言来显示不同语言（中文、英文）？
- 是否使用jquery？
- 几十K的jquery是否会消耗过大的带宽，或减缓页面加载速度？
- 需要统计一下浏览器访问量占mirrors总访问量的比重
Zhang Cheng
关于主页的directory browsing，我想这样实现：1、浏览器访问directory时，重定向 /path/to/dir/ -> /index.html#dir=/path/to/dir/在index.html中，用js读取url中的参数，并用ajax去取 /path/to/dir/?anything，nginx不对带参数的directory访问进行重写，因此正常的返回dir list内容，由前端index.html的js渲染。2、lftp访问时，不做任何重定向。
Bojie Li
> 关于主页的directory browsing，我想这样实现：
> 1、浏览器访问directory时，重定向 /path/to/dir/ -> /index.html#dir=/path/to/dir/
> 在index.html中，用js读取url中的参数，并用ajax去取
> /path/to/dir/?anything，nginx不对带参数的directory访问进行重写，因此正常的返回dir
nginx不对带参数的directory访问进行重写，这是rewrite规则里指定的，还是nginx本身的特性？
> list内容，由前端index.html的js渲染。
> 2、lftp访问时，不做任何重定向。
如何判断是浏览器还是lftp？UA不准啊。用javascript而不是301/302应该更好吧，lftp不会follow js的跳转。
Zhang Cheng
nginx不对带参数的directory访问进行重写，这是rewrite规则里指定的，还是nginx本身的特性？
如何判断是浏览器还是lftp？UA不准啊。用javascript而不是301/302应该更好吧，lftp不会follow js的跳转。
Bojie Li
> 用UA判断即可。正常情况下，lftp的UA带lftp字样，浏览器不带。谁手贱改UA的自己玩去，我们不用管那么多，这种边界清况的处理没有意义。而且UA本来就是表达用户的意愿，用户喜欢以lftp还是浏览器的方式去浏览，是他们的自由，管他们用什么工具。
>
> 使用js的话，需要解决的问题前面提过，要自己编译nginx加入fancyindex模块，或者后台再跑一个apache做dir listing。
我还以为你是在让我们用fancyindex……我试过一次，是可以用的，但稳定性未知。
Bojie Li
On 10/13/12, Zhang Cheng <steph...@gmail.com> wrote:
> 关于主页的directory browsing，我想这样实现：
> 1、浏览器访问directory时，重定向 /path/to/dir/ -> /index.html#dir=/path/to/dir/
> 在index.html中，用js读取url中的参数，并用ajax去取
> /path/to/dir/?anything，nginx不对带参数的directory访问进行重写，因此正常的返回dir
> list内容，由前端index.html的js渲染。
> 2、lftp访问时，不做任何重定向。
>
> （其实以前曾经有一段时间，mirrors的dir list是由apache做的，apache直接可以指定dir
> list的head.htm和footer.htm，可以应用于所有的目录。nginx自己编译加入fancyindex模块(非官方)也可以实现。）
>
> 关于jquery的流量问题，这个根本不用担心。几十k的jquery，相对于整个源站来说，根本不值一提，相对于用户访问的其他任何网站来说，也都不值一提。
>
> 另外mirrors.ustc并不会有太多的浏览器访问，大家只是偶尔come
> by，因此不建议在上面放太多的内容。所以我现在觉得，在这上面还是不要放太多咨询类的内容，被阅读的量太小。而与源站本身比较关系密切的信息，例如每个源的热度，这个放在其他地方组织并不合适，所以就放在这上面。而且这些信息对于偶尔come
> by的用户来说比较有趣，有吸引力。放一些新闻咨询之类的，对用户没有吸引力。
>
> 2012/10/13 Bojie Li <boj...@gmail.com>
>
>> mirrors.ustc.edu.cn
>>
>> - 为保持与lftp等工具的兼容，在directory listing中javascript跳转到Web首页
>> - mirrors首页采用自适应的宽屏设计
>> - 首页左侧显示若干发行版图标
>> - 图标按照热度调整顺序，这个可以人工定期来做
>> - 点击每个图标，在首页主内容区ajax显示：
>> - 发行版的简要介绍
>> - 大按钮Get Latest Version（下载ISO）
>> - 大按钮Help（链接到帮助）
>> - 软件包搜索框（software store）
>> - 首页主内容区，默认为一些mirrors简介，点击发行版图标后被覆盖
>> - 首页右边栏：
>> - 新闻动态，发行版新版本的发布信息。mirrors上适合放这种有点UGC性质的信息吗？
>> - Mirrors Lab
>> - 发行版趋势概览
>> - 关于我们（链接）
>> - 捐赠（链接）
>> - 镜像同步状态页面加上CSS
>> - 发行版趋势页面，比概览更丰富的统计指标，用张成说的日志分析和自动画图
>> - 能否根据浏览器的语言来显示不同语言（中文、英文）？
>> - 是否使用jquery？
>> - 几十K的jquery是否会消耗过大的带宽，或减缓页面加载速度？
>> - 需要统计一下浏览器访问量占mirrors总访问量的比重
>>
>>
>
>
> --
> Cheng,
> Best Regards
>
Zhang Cheng
@张成 你认为在mirrors上放硬又黑导航条（LUG网络服务导航，mirrors是其中之一）是否合适？mirrors是不是从属于LUG的关系？
我觉得没有问题。mirrors由网络中心赞助，LUG维护。并且mirrors这个‘项目’（包括最早的debian）从一开始就是由LUG做技术支持，将来也是。
Zhang Cheng
2012/10/12 Bojie Li <boj...@gmail.com>
好吧，我表示不能理解……一个帖子下面的讨论会分成几个分支？每个回复及其回复树就构成一个分支吗？
有点类似这个意思。主要是语意上的分支，比如我们最开始在讨论mirrors.ustc，然后后来变成git，然后后来变成这样一个wiki工具，就是主题的漂移。这就是不同的分支。如果我们能捕获这样的主题的漂移和之间的依存关系，那就能帮助用户更好地理解某段对话。这个提取出来的标签是以主题为单位，还是帖子为单位？显示在什么地方？这是一个还没有确定的问题。目前我的想法是以主题/分支为单位的。比如用户打开我们的这个thread，首先看到的就是3个标签，mirrors.ustc, git和wiki工具（这个是很理想的情况啦，先不考虑我们如何去实现），然后她对哪个主题感兴趣就点进去看其中的讨论。也有可能这个讨论很长，又有几个 不同的子话题。这时候用户就可以继续通过标签，搜索或者用户排序的方式来找到感兴趣的帖子/分支，从而完成知识的获取和讨论。
Yan Wang
Bojie Li
Nodnod, 如果对这样的话题感兴趣的话，不妨先讨论一下为什么要这样做，好处是什么，然后再看如何去实现。
我的想法是在使用这个邮件列表参与讨论的过程中，学到了很多东西，有很多启发。但也遇到了一些不便：
- 一些觉得很喜欢的东西不方便存档保存。虽然可以手动拷贝，gmail加星，evernote存档，但是：
- 一方面这都依赖于一些通用的知识管理工具，事后搜索的时候因为很多知识都混杂在一起所以会不方便（这一点不是很确定，因为我没有实际去用evernote整理一份这样的“精华区”出来）。
- 另一方面这样只有一个人在整理，缺乏质量上的保证，比较低效，同时往往也丧失了更多的讨论的机会。
- 讨论的时候实际上形成了一个话题树，但gmail或者group是根据时间顺序线性展示的。这就会造成浏览的时候非常低效：
- 整个group都很精彩，所以我有动力把全部回复看完，但很多时候别人讨论的东西和我的领域又不相关，只能一个一个浏览，找到精彩的再细读。如果能把这个树状的结构直接可视化出来，辅以关键字会不会好一些？
- 没有引入用户对邮件的评价体系。如果有这样评价体系的话，即使有些发言和我的领域不直接相关，但大家都觉得它很棒，这样的帖子也不会被错过。
- 邮件的质量相对受限。比如某封邮件很精彩但是有错别字，别人就无法修改。或者一个观点很新颖但缺乏论据支持，另一封邮件提供了佐证，没办法整合起来形成一个完整的以后能直接拿来用的论述。
所以这里提出的解决方法是：
- 知识库：提供一个wiki页面的集合，和方便的“整合邮件进知识库”的功能。在浏览界面上就可以把一个指定的邮件整合进一个指定的知识库的页面（当然需要人工编辑）。
- 讨论的可视化：向前面说的那样，引入树状的浏览模式，辅以关键字提取来帮助甄别有价值的讨论。同时引入用户的评价体系。
接下来的问题就是：这样的想法有没有道理？如果真的有这样一个产品做出来，你们会觉得吸引人或者会去使用吗？有什么类似功能的产品呢？Best Regards,
Yan
2012/10/12 Bojie Li <boj...@gmail.com>
2012/10/12 Yan Wang <gra...@gmail.com>:
> [OT] 有没有可能把邮件列表的内容搞成一个Wiki,首先是技术问题。Groups的邮件可以从Web抓取，用正则表达式分析旧版groups的HTML（新版groups是ajax的，我没分析明白）。当然如果有本group元老级的人愿意把所有邮件SMTP取下来打个包，就不用我们费时间写爬虫了。Google有防机器人机制，如果写个爬虫持续抓取会被封IP（至少搜索功能是这样的）。当然可以在脚本里加上一定的延迟，但这样抓取时间就长了。
> 这样大家可以编辑里面的内容并且vote有价值的帖子，相当于reddit和wiki的合体。这样的产品如果能做出来的话会有利于大家合作整理知识，也非常有意思。
然后是非技术问题。每个thread作为一个词条？每个post作为词条内的一个section？然后大家就可以把thread中的回复进行整理，做成一篇可以看的文章？这样做的目的是什么？为什么不让大家到groups的Web页面直接去看、搜索？