2021-12-13 声明:我反对自己的意见
才发现思源本身是有自己的方法论(daily notes 系列)建议或者说适配方法论的,思源的功能建议是依照该方法论来提供功能支持,因此我原本试图适配更多用户的建议可能会对该方法论产生困扰,思源似乎专门对愿意执行该方法论的人提供软件支持。
同时我自己也觉得该方法论具有先进性,觉得自己的理解不够深入,因此我反对以前提出的意见,并愿意看看该方法论的探索用户能把软件推进到什么程度。
原文:
对此问题 2021-11-25 二群有过比较激烈的讨论,之前也有两个帖子 ①② 提过这个问题并进行过对应的两次更改。其中有人完全不理解为什么要支持自引,并且可能以投票形式来决定最后改动,我可以提供具体的使用场景,并且希望投票结果仅供参考,由开发者决定最后的形式。
具体例子
例如我需要建立一个《睡眠-呼吸暂停综合征》的条目,而打鼾是其中最有代表性的特征之一,因此在别处我往往会使用“打鼾”这个锚文本来指向《睡眠-呼吸暂停综合征条目》。除此之外还有别的病因也会出现“打鼾”这种常见病症。对于各种常见的大量症状我并不会一个个去做块引,而提及能帮我把他们联系在一起,提醒我这个症状是被标注的,是常见或者特殊的,这样也很方便。
与此同时,在《睡眠-呼吸暂停综合征》条目下,如果虚拟引用支持自引,那么里面必然提到的“打鼾”也会被标注,这样可以提醒我“打鼾”他是常见或者特殊的,也能在此直接通过提及看到其他的出现“打鼾”或者指向本条目内容。支持自引是有使用场景的,一些解释内容更长的大段条目、更不适合用来当做锚文本的块都需要可自引的提及来帮助自己标注。
由开发者来决定与自定义
投票来决定删减局部小功能可能不是一种很好的方式,有几个难点需要解决:第一个是投票的人不一定代表依赖用户和未来用户的大多数,可能是活跃发言的大多数,也可能是关注消息的大多数,高质量样本的采集是统计的重点;第二个是今天的大多数明天可能就是少数,几次删减后满意的人数交集会少很多,没人能保证自己一直是大多数;作为二的延伸,即使是少数也是需要保障的,就像是某些选举里的最低名额保障,以及两派人拥有不同的投票权重。这里提一个公开发言常常会有的现象沉默的螺旋。
当然不是说开发者就不允许删除功能,只是多考虑这个功能的使用场景是否符合自己的目标群体,删除或保留功能是仅仅让人不舒服,还是破坏了一部分使用场景?好不好实现自定义同时满足?由需要改变的用户说明使用场景和价值来说服开发者而最好不要简单投票决定,由开发者自己决定。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于