【RFC-082】开发类似Google Doc或Github的逐句/字评论功能
变更理由:品葱的重要功能是用类似开源项目的方式,集体完成一个项目或文档,如社区公约、资料汇集等。
这就需要实现逐字逐句的评论或修改功能,能够实现这个功能的是Google Doc,以及Github, Gitlab, Gitbook等平台,但这些平台的缺点是注册门槛高或者使用门槛高。
变更内容:葱或可以依托某个平台,例如Gitlab,开发出逐字句评论,甚至是修改的功能,实现文档的集体编写。
讨论时间:无限。
参考资料
https://www.gtricks.com/docs/how-to-go-anonymous-on-google-docs/
https://lifehacker.com/how-to-create-an-anonymous-collaborative-google-sheet-1821990886
https://etherpad.org/
https://firepad.io
http://collabedit.com/
https://doc.owncloud.org/server/9.0/user_manual/documents.html
https://floobits.com/
https://cryptpad.fr/
https://github.com/yangshun/tech-interview-handbook
https://www.gitbook.com
github上修宪评论这种效果很棒
这就需要实现逐字逐句的评论或修改功能,能够实现这个功能的是Google Doc,以及Github, Gitlab, Gitbook等平台,但这些平台的缺点是注册门槛高或者使用门槛高。
变更内容:葱或可以依托某个平台,例如Gitlab,开发出逐字句评论,甚至是修改的功能,实现文档的集体编写。
讨论时间:无限。
参考资料
https://www.gtricks.com/docs/how-to-go-anonymous-on-google-docs/
https://lifehacker.com/how-to-create-an-anonymous-collaborative-google-sheet-1821990886
https://etherpad.org/
https://firepad.io
http://collabedit.com/
https://doc.owncloud.org/server/9.0/user_manual/documents.html
https://floobits.com/
https://cryptpad.fr/
https://github.com/yangshun/tech-interview-handbook
https://www.gitbook.com
github上修宪评论这种效果很棒
10 个评论
我预设的前提:希望品葱发展成类似知乎一样的大众社区,主要话题是政治。
对于用户众多的社区来说,用户的讨论才是最主要的内容。
对于大众用户来说,太多的工具提高学习成本,提高了用户门槛。这一点题主也提到了。
虽然现在,或由于需要发泄情绪,或尚未习惯非辩论性质的沟通方式,很多人喜欢抠字眼钻牛角尖,但是我们不应该忘记,品葱是个大众社区,不是咬文嚼字法庭辩论的地方。开发这个功能,反而可能无意间鼓励用户盯着字句相互攻讦,无视自然语言的模糊性,忘记交流的目的是为了促进理解。
“社区公约”这类内容,逐字逐句地讨论、修改、校对固然可以达到匠人般的请准,但是我不认为有这个必要。想象一下,假设我们现在引入了这个功能,而且只在某个“公约”上开放这个功能,看上去很美,按照现在讨论规则的规模,大概十几个用户各自留下了标注、评论。如果一直开放这个功能,不同看法的人终将陷入编辑战。这个公约到底什么时候定稿呢?如果说开放一段时间就关闭这个功能,那么谁来决定什么时候定稿,又要怎样确定呢?
这还只考虑了目前少数用户的情况。如果品葱人数越来越多,以上问题将更加复杂。
我理解题主的用意,但是认为这个功能优点有限,负面作用很大。
(诛心一分钟,我想题主可能是个理工科学生,有点追求最优解法、一劳永逸的思维习惯。然而政治的目的不在于达到静态的结果,而是不断拉锯、不断否定从前。西西弗斯之石如是也。)
对于用户众多的社区来说,用户的讨论才是最主要的内容。
对于大众用户来说,太多的工具提高学习成本,提高了用户门槛。这一点题主也提到了。
虽然现在,或由于需要发泄情绪,或尚未习惯非辩论性质的沟通方式,很多人喜欢抠字眼钻牛角尖,但是我们不应该忘记,品葱是个大众社区,不是咬文嚼字法庭辩论的地方。开发这个功能,反而可能无意间鼓励用户盯着字句相互攻讦,无视自然语言的模糊性,忘记交流的目的是为了促进理解。
“社区公约”这类内容,逐字逐句地讨论、修改、校对固然可以达到匠人般的请准,但是我不认为有这个必要。想象一下,假设我们现在引入了这个功能,而且只在某个“公约”上开放这个功能,看上去很美,按照现在讨论规则的规模,大概十几个用户各自留下了标注、评论。如果一直开放这个功能,不同看法的人终将陷入编辑战。这个公约到底什么时候定稿呢?如果说开放一段时间就关闭这个功能,那么谁来决定什么时候定稿,又要怎样确定呢?
这还只考虑了目前少数用户的情况。如果品葱人数越来越多,以上问题将更加复杂。
我理解题主的用意,但是认为这个功能优点有限,负面作用很大。
(诛心一分钟,我想题主可能是个理工科学生,有点追求最优解法、一劳永逸的思维习惯。然而政治的目的不在于达到静态的结果,而是不断拉锯、不断否定从前。西西弗斯之石如是也。)
已补充参考资料,请技术大佬评论方案,或者直接集成一个Pincong Wiki
不止合作编辑社区公约,很多文章其实都适合逐字评论,另一翻风味和乐趣。
你可能没体验过这种工作方式的高效神奇奇妙深刻,体验过之后保证你欲罢不能。
再说这是新增功能,不跟现有功能冲突。
你可能没体验过这种工作方式的高效神奇奇妙深刻,体验过之后保证你欲罢不能。
再说这是新增功能,不跟现有功能冲突。
没有必要太复杂,像PTT那样,短评之前用一个标志区分开赞踩足矣,毕竟很多人翻墙不易,没意义的东西应该尽量少以节省流量
恰好相反,我对类似的工作方式有些经历,工程类、事实类等有唯一解、最优解的项目,确实非常合适。然而正好也有些负面经验,在议事类没有唯一解,而是为了达成compromise项目,非常容易陷入编辑战或者冷战中。
对于面向大众的平台(我是这样看待品葱的),类似于“若无必要,勿增实体”的功能设计原则也是需要考虑的。
对于面向大众的平台(我是这样看待品葱的),类似于“若无必要,勿增实体”的功能设计原则也是需要考虑的。
我明白你的意思,但是功能冗余不一定是优点。回想一下十年前的门户网站,所有功能都有,但是可用性实际不如当下流行的扁平极简风。我不赞成这个功能的主要原因不在于“它不好”,而在于“没这个需求”。