存档

2019 年 01 月 - 2 文章

是否应该让用户自己来分类内容有感

别让普通用户做选择,不然他们会把简单的事情复杂化。对于普通用户,发布内容时功能越简单越好,甚至是只需要一个标题。不要提供分类、节点、标签的选择,因为普通用户都有“选择困难症”。 这和垃圾分类是类似的(当然,我不是说普通用户发布的内容是垃圾)。只有很少一部分人在扔垃圾时会考虑适合的垃圾桶。我们的终极社会(共产主义)实现的前提是人民的素质必须到达非常高的地步,我们理想中的社区也需要用户在很大程度上达成行为的一致和思想上的共识。 而在目前,这显然是不可能的。高速发展带来的问题主要是内部矛盾,而内部矛盾通过系统化的规则约束和引导来解决是较为稳妥和可行的。在内容分类这个问题上,我们要让一部分有强烈分类意愿的用户来达到他们对分类的渴求: 隐藏分类入口,让有探索精神的用户发现并使用它设置管理分类的权限,让具备选择能力(权限)的用户帮助其他人分类 只有这样,我们才能把社区中混乱的信息逐步进行规整,将社区的管理工作逐步交给其他参与者来做。随着管理权逐步分散执行,最终实现自治的社区。

More...

GitHub Star 的意义

 

以目前来看,GitHub 上有用的仓库大致分为两种类型,项目和文档。 以代码为主的可运行项目 这类项目(排除那些没有替代品的)是有具体使用场景的,或是框架或是应用。如果从星数看,这类项目是比较难获得星的,因为: 项目具体的使用场景相对固定,这也就决定了其目标用户毕竟是少数项目的效果非常直观,通过代码质量、运行结果、文档、社区等可以很容易对比出同类项目的优劣 如果你“看不起”或者“看不懂” 的项目有较多星,说明的确是对一部分人有用,这是真的有价值的项目。它们节省了目标用户的时间、减少潜在的缺陷等。另外,这类的项目同质化严重,基本都大同小异,但它们之间的星数还是会有数量级上的差距的,这就是优秀、一般、一般般的直观差别。 如果要从设计或者代码上看这类项目有啥值得学习的,那可能还真没有。因为这类项目的本质其实就是干了一些脏活累活,而正是这些脏活累活很少人愿意自己干,更何况干得漂亮的了。 漂亮的 API 背后都是丑陋不堪的实现,丑陋是因为我们不想看,看不懂,发现不了它们的美。 以 Markdown 为主的文档 这类仓库在我看来大部分都是没用的: Awesome-xxx面试宝典-xxx 书籍收....

More...