使用一个github的文件去维护规则列表的这个想法,我现在已经不这么想了,因为贡献规则表的知识量难度很高,下面我这么给你描述一下关于贡献规则描述的难度:
1.你需要能够顺畅访问github,光是这一点,已经让大多数人贡献规则这一点给拒之门外了,我知道有办法能够顺畅访问github,懂一点的人可能了解steam++,再懂一点的人可能了解科学上网代理工具,但是不要觉得这些人很多,也不要觉得会用这些工具的人很多,事实上这个规则贡献就应该设计成一个人人都能够贡献的设置项,只不过可以更换规则更新的源头,也就是能够更换url,我看了你说的那个关于订阅规则的构想,这一点和我期望的很接近了,但是又不太一样,我可能会这样设置一下关于能够贡献规则的人群:1.使用有网络的电脑2.会使用电脑在软件上点点点3.对自己电脑的上垃圾清理这方面有那么一丢丢的兴趣的.
2.你需要能够至少是网页版的github的使用方面的相关知识,项目合作基础知识和github的仓库相关操作,例如github是如何合作的,这个流程你得知道,仓库的fork是什么干什么的你得知道,修改仓库后如何申请合并推送到原始项目中去,至少我现在对这个也是一知半解的状态.以前我也搜一些关于如何申请合并项目到原始项目中这一块的教程,但是教程的页面和现在的都不一样,不是这个地方的单词有一些不一样,就是那里的按钮被放到另一个层级里去了.
3.如果我突然看到一个文件夹没有被标记描述,但是我又想要立即对其进行标记,我会发现这有点麻烦,我需要打开浏览器,找到关于规则贡献的那个仓库,进行编辑文件,请求合并,这里还不包含我要查找我添加的规则里面是否有重复的,这一切的操作,都只是为了贡献一条规则.就是为了这么一件小事.

综上所述,我对于贡献规则的设想是:只一个编辑框和一个提交按钮.甚至如果不想贡献规则的话,只显示一个[贡献规则]的入口,而且这个入口要让用户一眼就可以看到.

所以,这就要求开发者对于规则贡献的功能进行内置,自动进行本地规则文件添加,自动发送规则上传请求,在服务端进行去重操作,然后以后每次使用都会自动更新一下最新的规则.先上传在同步,永远都是这个顺序,防止用户自己的规则关键字和对应描述没有在最新的规则里

或者干脆就做成去中心化的,只要超过2个人用,就自动互相同步,互相去重,关于条目关键字可能会重复的,就自动让一个条目关键字能够关联多个描述,如果描述完全一样,则对描述进行去重.

希望在扫描出来的文件夹描述里添加一个编辑 描述的功能 编辑后自动保存在folders_description.yaml文件里 #29

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

希望在扫描出来的文件夹描述里添加一个编辑描述的功能编辑后自动保存在folders_description.yaml文件里 #29