首先，issue区的最主要的作用就是提交“bug”，这些bug既包括常规性质游戏bug，也包括一个载具缺失（也可能是多了）什么该有的性能，后者也就是大家最常提交的issue。
而后者的这类issue需要玩家提供资料去证明，毛子的要求是一项主要证据或者是两项次要证据。
前者可以是操作手册，展板，或者是载具的实际图片，解密的官方资料
而后者则可以是专业的书籍杂志之类的二手信源。同时，这些书籍杂志必须得是来自两个不同的出版社，比如你不能拿着一本书的两页内容作为两项证据去证明，严格一点甚至不能由一个出版社的两本书上的资料作为证据去证明，而这些二手资料是必须要有两份去由开发者交互印证的，同时这些资料除了作为证据的页面以外还需要提供封面和页码。
如果资料不够/不完整会被管理员要求更多的资料。
如果没有实质性的资料或者单纯的是乱来就会直接被标记“not a bug”
非官方网站的网址和百科是不会被认可的
最后这些资料是可以由issue提交者隐藏只给官方人员看的！所以有时候真的不是有人随便交了点东西就被过了（虽然偶尔也会有这种情况）

如果提交的issue满足了上述的内容，那么这些issue会被管理员（也就是那些给issue打上各种标记的gaijin官方人员）进行审核，没有问题之后就会发给开发者。
在这个过程中issue会被标记“acknowledged” 也就是我们所说的“通过了，或者是承认了”，但实际上的情况是acknowledged在这里真的不是“承认”的意思，而是“理会”，也就是管理员告诉玩家官方人员（开发者）收到了，至于会不会修，什么时候修，则是由开发者去决定。也就是我们喜闻乐见的“承认不等于实装”了。

在这个时候，如果开发者认可了你的资料，并且想修，那就会在未来的某个版本进行修复，并标记“fix”。这是最好的情况
如果开发者认可了资料，但是不是很想修，那大概率会装死，issue一直是“acknowledge”，你发再多的issue都会被标记成“重复”，什么时候修就真的只能看毛子心情了，这也是最常见的情况
如果开发者不认可你的资料，那么就是喜闻乐见的“acknowledge”变成“not a bug”了，也就是bvvd不等式时间。
当然还有种特殊的情况，开发者认可了你的资料但是就是不想修，而且还是明说的那种，最典型的例子就是豹2PSO的可装附加甲。

另外一个比较重要的点是现代载具的装甲相关的issue是不会被当作“bug”而是当作“suggestion”也就是建议提交上去的。大家能看到某些通过的issue下面会有“submit as suggestion”，这也意味着这些issue是真的由开发者随心所欲的去决定要不要去修而不是当作bug去修，人话就是毛子保留了不修的权力，而且这些issue的优先级都会很低。
类似的像是m829a3，dm73这种新弹，99的激光压制，都是作为建议交上去的，交上去的原因是因为提交的资料被管理员认可了，而不是真的要发！

所以大家看完了这个流程，就会发现很多时候其实那些管理员是单纯的履行了自己的职责的，也就是充当“传话筒”这个角色，但是由于决定权在开发者手上，他们只是执行者，于是就悲惨的成为了玩家的宣泄渠道“资料都这么全了为什么not a bug了！”而开发者则在幕后笑嘻嘻

比如这个帖子（这里绝对不是挂人）
帖子里的图片是某个恶名昭著的管理员转发开发者的回复，但是被这个帖子的楼主当成了是这个管理员自己的意见（这里不是指责这个楼主或者是给这个管理员洗地）
但其实虽然这位恶贯满盈但是他真的只是把开发者的话原封不动的转过来而已。

当然了，这可绝对不是为个别的管理员洗地，因为有的管理员连传话筒都当不好，资料不细看就直接否决，这里就不指名道姓了。

所以为什么“acknowledged”会从“收到”变成“承认”我一直没想明白真就翻译一下看第一个是吧

最后再说几个小规则，
如果一直发重复的无用issue，会被直接封禁发issue的权利
一个issue最好只指向一个载具的一个问题，比如A载具缺少内衬，装甲错误，没有热成像，B载具没有热成像，那就需要单独发四个issue，而不是“A载具和B载具缺少热成像”，或者是一口气把A载具的资料全糊上去把三个问题集中在一个issue里
评论区如果一直发无用言论，会直接被管理员关闭issue的评论区（但是作者还是可以更新issue），并警告不要再评论区乱发东西了。所以大家的“i agree”其实是违规操作，评论区的用途是用来给其他人补充资料的，当然不可否认的是真的刷上i agree反而会引起管理员的注意（虽然是负面的注意）

所以大家看到issue过了之后既不要抱太大希望，也不要掉以轻心，当然了也不能因为真正fix概率小就不发了，载具性能的还原都得是我们自己去争取的！

说的很详细了，很多情况下是开发组的问题

最后，看到这，大家也应该能意识到毛子这个issue体系的问题了。
诚然，由管理员来收集审核玩家发上去的资料能够减轻开发者的工作，让开发者集中于开发工作中（虽然每次毛子大更新都有一堆bug/换皮/还有赶工也不知道平时在干什么）但是这也造成了一个问题就是玩家和开发者交流的效率极其低下，而且开发者们本身（甚至包括部分管理员）都充斥着傲慢与对玩家的敷衍。
比如当一个玩家费劲心思找了各种资料并长篇论述向开发者解释问题后，开发者可能根本就不关心也不在意玩家说什么，找到了一个问题就直接否决你的整个issue甚至是全部资料。
又比如上面帖子里的那个issue里的情况，开发者根本就是极其敷衍的态度应付玩家。
而且开发者们本身还无比的“双标”，典型的例子就是自己用一个excel表格和上个世纪的旧文件去削弱某个载具（为了避免引起不必要的争端和节奏就不指明了是哪个载具了，虽然看描述大家也能看出来），同时对玩家提交上来的各种详细打脸资料一幅我不听你没有证据的丑态。
再加上个别的不负责任的管理员，最后就造成了一波又一波的节奏和大家喜闻乐见（但是我真的不想见）的毛子笑话。以及玩家们想冲都不知道冲该冲谁，能冲谁，最后只能拿管理员开刀了。

相当于管理员做初步过滤，acknowledge的会被送到实际的策划和程序部门，但如果后期再被策划否了也是有可能的。