Skip to content

Latest commit

 

History

History
43 lines (22 loc) · 2.78 KB

toyou.md

File metadata and controls

43 lines (22 loc) · 2.78 KB

给维护组与社区的话

如果你想加入维护组,可以查看开往博客,通过文章作者查看最近活跃的维护者。这里是一些开发规范和开发理念,便于新的维护者加入。

项目说明

static文件夹会被完整的解码,static/libraries里会存档一些跳转样式

src文件夹建议放置一些单独的页面,譬如首页。首页样式可以在index.js中设计

blog文件夹放置的是博客,上传MD或MDX文件即可生成博客

docs与custom/post文件夹放置的是文档,也是上传MD或MDX文件即可生成文档。

完整请参见docusaurus

开发理念

维护组要避免外行指导内行

一个广为流传的例子是:每次看见别人给我发一长串59秒的语音就很奔溃,如果中间没听清楚,还要从头开始。这个功能被网友诟病已久,但是为什么微信没有语音进度条呢?

是张小龙团队没有听到用户的声音吗?是实现逻辑复杂且技术门槛高吗?显然都不是。100多年前,福特汽车创始人亨利·福特跑去做用户调研,“您需要一个什么样的更好的交通工具?”几乎所有人的答案都是:“我要一匹更快的马”。

维护组内与社区中存在许多非专业的开发人员,对于他们的需求要多思考背后原因。他们给出的方案背后的真正诉求是什么。

技术是用来达成目的并提高效率的

一处修改,处处生效。开往面向GITHUB,同时在用户不易登录GITHUB时可以通过网站查询。功能设计的最基本的要求是:确保各方看到的消息是一样的同时,维护组仅仅需要维护一个存储库。存储库发生修改,处处生效。如果没有现成的方案,那就思考如何做这个方案,这才是技术该做的。

去中心化与技术栈

个人色彩浓厚的项目停止维护的原因有很多,大多是到了人生的某个阶段无法继续付诸精力。除了一代代交接,去中心化的维护方式或许成为当下最好的解决方案:由用户提出讨论。维护组自愿认领,所有流程公开可以极大减少沟通成本。

注意:开源社区的参与者通常技术栈各不相同且维护时间不定,统一技术栈更便于交流。

尊重流程

避免没有执行的讨论,也不要提出一个无法解决或空泛的问题,让我们看看你的代码效果。好的维护者不单在讨论区活跃,代码贡献也该是活跃的。

彼此尊重是社区的前提,讨论问题针对当前事情提出解决方案,赞成或反对,仅此而已。

允许过失,但不要容忍过错。过错指明知道这样不对但是还是做了。过失指并不知道这样做会有什么后果。