参与开发的方式及其规范

[1lck]

1. 在进行开发前，需把开发的任务以issue的形式提交，如开发内容过大，需等管理员进行方案讨论
2. 如issue区已经提出的问题，可在该issue下回复：/assign 代表自动认领此issue，issue的认领有一定的期限的，超时还没有关联的PR会自动进行提醒，如果再进行超时了的话对应issue会被自动释放
3. 需注意：所有PR合入目标都应该是preview分支而不是main分支
4. 如功能点过大，需对pr进行拆分，确保单个pr原子，pr上需关联issue链接。单次PR改动最好控制在15个文件以内，不要随意改动已有的Skill、CI流水线和相关的shell脚本
5. 正在开发还未开发完的pr请设置为Draft状态，开发结束需要review时可以改为open状态
6. 开发完成后，可在pr下 @xiaoyumuxi @1lck @Mucheen 来进行 review，当然也可以使用仓库的review机器人（@lithe review）但是改动过大过多可能导致机器人审核超时空返
7. 需求排序是优先修复Bug，然后再是开发新的功能和对其IDEA的部分设计，对于正确标记的P0级别的Bug应当尽可能块的进行修复。
8. 对于标签wait-Freezing的issue暂时不接受PR，仅有在专项冻结期间去定点进行重构或者修改，因为涉及到原先的历史性代码
9. 项目里面有相关的Skill来负责测试和记录踩坑的地方从而方便进行迭代——http://notes.lithe.top/ ，另外开发者可以使用Code Review的Skill先进行一次自审减少审核者工作量
10. 如果你是MacOS用户但是想要开发Windows相关的功能，可以看看我们wiki里面相关的描述 https://github.com/1lck/Lithe-IDEA/wiki/%E5%85%B3%E4%BA%8E-MacOS-%E4%B8%8A%E9%9D%A2%E4%BD%BF%E7%94%A8-Windows-%E8%99%9A%E6%8B%9F%E6%9C%BA%E7%BC%96%E8%AF%91%E6%97%B6%E9%97%B4%E8%BF%87%E9%95%BF%E7%9A%84%E6%B5%81%E7%A8%8B%E4%BC%98%E5%8C%96 使用CI来辅助进行相关功能改进的验证，而不是使用更慢的在虚拟机里面进行编译的方案