我们是否应该尝试提高 issue 质量

[SALTWOOD]

最近感觉很多重复/无效/拒绝的issue，举个例子：这不是前一段时间正式版出了“内存优化”嘛，就出现了很多关于“设置页面可用内存字样消失不见”的issue。

Collaborators也在discussions里列出了常见问题，但是issue创建页面没有指向，导致一些反馈者为了活跃橙（不敢说全都是，但总有人是）根本看不到那些问题就直接交issue，就是所谓的“为了挖bug而挖bug”。

同时，确认项里写得明明白白，“我已在 Issues 页面 中搜索，确认了这一 Bug 未被提交过”，但总是有人要么不搜直接看都不看就勾选，要么就是随便搜搜，而且因为搜索关键词表达不明确根本发现不了反馈相同问题的issue。（就连我都抓到几个重复的，更别提那些比我更勤快的Collaborators了）光是PCL2这样开源不久的项目，它的issue编号甚至排得比某些更老的项目还后，甚至光是重复和被忽略的issue（截至现在共1108个）就占总issue数（1818）一半以上。

所以我建议龙猫稍微改进一下issue template，至少把常见问题放上去，要求反馈前先看一看，也能减少很多重复的issue

[zkitefly]

我觉得会有效果，但应该不大，毕竟你也说“为了挖bug而挖bug”不是么（

还有就根本不勾 “我已在 Issues 页面 中搜索，确认了这一 Bug 未被提交过” 的

[SALTWOOD]

也许可以试试，总归是有些效果（吧？）
况且也不是不可以对恶意找bug的人作处罚（我记得龙猫以前就因为一个人乱投issue把他禁言了1个月）
比如说取消资格、禁言之类的
参见#1984

[SALTWOOD]

总是有人只是因为不会操作而不是恶意找bug的，这种人能救肯定尽量就
那种看都不看甚至不勾的谁也拿他没办法，对吧？

[LTCatt]

事实上 issue 质量低的人不管你写什么他们都不会看，不会有用的……

[SALTWOOD]

但是对于一些真的想为Minecraft和PCL2做贡献的人来说确实挺有用，起码把能救的救了，病入膏肓的救不了就随他去

[SALTWOOD]

而且也可以放些规范、注意事项之类的，至少像错误报告传到一半提交的人会少些（

[zkitefly]

#2574

[WForst-Breeze]

活跃橙的确是提高社区活跃度的主要因素之一，并且占到很大比重，这也直接导致了低质量 Issues 很多。提交这些低质量 Issue 的朋友的目标无非两个：不为活跃橙什么的，只是想交 Issue，但因为想表达的太迫切，结果就不想去细看检查项（这种情况的确是有的，因为他们很希望自己的建议被采纳，这样会让他们感到很高兴 :D 然而通常此类 Issue 算不上低质量，反而通常一个 Issue 里塞了很多内容，一个个处理起来真的很麻烦），第二个就是单纯为了活跃橙，游戏崩了，交！网络不好，交！（没有讽刺的意思，毕竟谁都有个新手期，也是可以理解的啦~）。

说了这么多，无非想表达的是：真正认真交 Issue 的人一般不需要这些补充性的东西，因为他们会认真地搜索，这些对他们而言是冗余且不必要的；而不认真交 Issue 或是着急忙慌交 Issue 的人一般有了这些东西也不会看，因为他们不会认真看这些提示性信息，这些对他们而言同样是不必要的。

Collaborators 的话这点不用担心，因为我们本身就是协助去筛选 Issue 的，这是我们的主要工作所在啦~

适当的一些调整和完善我个人认为可行的，但让反馈者全读完这件事可能……

[SALTWOOD]

那确实是这样。但是加上这些提示有助于引导一些萌新度过新手期；至少各位Collaborators可以以一个更加积极的心态去处理issues（看到某些乱反馈的issue心情真的会不好）

总之加上可能会好一些

[iPodtouch6557]

世界80亿人，林子大了啥鸟都有（
很难保证每个人都有那么高的素质，再怎么尝试提高质量也会有**交一堆没用的issue……我们能做的只有亡羊补牢

[SuoHouDaiShi]

我有个想法
在日志与附件哪里强制要求上传至少1个的Log文件 否则不让交（如果能
我没啥能力 我怕拉pr又被龙猫丑拒）））

[LTCatt]

github 不支持

[SALTWOOD]

首先，GitHub没有这样的功能；其次，有些bug是不会记录在log里的