[DOC]建议删除Readme.md中的"支持QQ"

[mzltest]

据https://forum.koishi.xyz/t/topic/308 Koishi 的一些使用方式不被用户交流群所支持，如：

... 对接由腾讯公司推出的即时聊天软件 ...

以及论坛氛围：(仅举例) https://forum.koishi.xyz/t/topic/1652/30 《 Koishi 发布过 QQ平台 的适配器 》 https://forum.koishi.xyz/t/topic/3613/15

Koishi 没有支持过 QQ 平台（如果不算 QQ 频道的话）。

Koishi 的官方适配器支持包含 QQ 频道、OneBot、Discord、Telegram、Kook、Line、Matrix、邮件、飞书等等。这其中大多数平台的支持是非常完善的。

Chronocat 是社区项目，与官方无关
Chronocat 支持的是 Red 协议，你可以类比成过去支持 OneBot 协议一样
适配器生态丰富对应的是「跨平台」，本身与是否高性能没有关系

综上，应该删去Readme.md对于QQ的相关描述,以免造成误导,或者至少应该明确说明QQ不再受官方支持，目前的描述： 支持 QQ，Telegram，Discord，飞书等主流聊天平台，支持多账户和跨平台数据互通

如果一个用法无法得到官方帮助与支持,是否还应该宣传说框架支持?

PS.不是抬杠.目前各大主流平台,包括知乎等都在说koishi支持qq,可以部署qq机器人,但是很多用户求助后才知道交流群和官方都不支持qq群,因此我觉得这个是有误导性的.

[MaikoTan]

Isn't QQ Guild also QQ?

QQ 頻道也算吧？

[mzltest]

Isn't QQ Guild also QQ? QQ 頻道也算吧？

那应该明确说明是QQ频道,一般说QQ的理解都是QQ群 在readme相当于门面的这个文档里更应该明确说明两者的区别

[ilharp]

我懂你误解的点了，你是看了外部的宣传然后产生了误解

Koishi 没有支持过 QQ 平台（如果不算 QQ 频道的话）。

这句话的意思是，Koishi 官方没有为「对接 QQ 机器人」这件事给予官方的「支持」（Support），也就是说这件事不在 Koishi 的承诺范围内。

目前各大主流平台,包括知乎等都在说koishi支持qq,可以部署qq机器人

这句话的意思是，Koishi 有「对接 QQ 机器人」的能力（Ability），你可以使用 Koishi 对接 QQ，但这是社区小伙伴研究的结果，而非 Koishi 团队实现的。Koishi 官方没有做这件事，自然也无法支持这样的操作。但你仍然可以使用社区提供的方法对接 QQ。

[mzltest]

我懂你误解的点了，你是看了外部的宣传然后产生了误解

Koishi 没有支持过 QQ 平台（如果不算 QQ 频道的话）。

这句话的意思是，Koishi 官方没有为「对接 QQ 机器人」这件事给予官方的「支持」（Support），也就是说这件事不在 Koishi 的承诺范围内。

目前各大主流平台,包括知乎等都在说koishi支持qq,可以部署qq机器人

这句话的意思是，Koishi 有「对接 QQ 机器人」的能力（Ability），你可以使用 Koishi 对接 QQ，但这是社区小伙伴研究的结果，而非 Koishi 团队实现的。Koishi 官方没有做这件事，自然也无法支持这样的操作。但你仍然可以使用社区提供的方法对接 QQ。

是这样,我的意思是如果官方不提供support的话,就不应该在readme第一眼看到的门面上说支持QQ.我认为一般用户看到的支持应该就是有问题可以找官方的支持．

而且如果回到那句话看的话

支持 QQ，Telegram，Discord，飞书等主流聊天平台，支持多账户和跨平台数据互通

我相信除了QQ以外的其他平台都是Support的那种支持,而在这里将一个Ability级别的支持与Support级别的支持相提并论是不妥的.

建议改为:

支持 QQ频道，Telegram，Discord，飞书等主流聊天平台，支持多账户和跨平台数据互通；也支持QQ群,但官方并不提供此平台的任何协助

让新用户一眼看见QQ群不会提供Support,也就是"你要靠你自己了",这样也会避免后续可能的纠纷.

[ilharp]

我认为这是合理的，支持

[MaikoTan]

There's not only group QQ that is supported by the community, but there are more such as wechat, wecom, Minecraft, and so on. I think it is better to either mention them each by each, or just leave them alone unmentioned.

社区支持的不仅有群QQ，还有更多如微信、wecom、Minecraft等等。 我认为最好要么逐一提及它们，要么不提及它们。

[mzltest]

There's not only group QQ that is supported by the community, but there are more such as wechat, wecom, Minecraft, and so on. I think it is better to either mention them each by each, or just leave them alone unmentioned.

社区支持的不仅有群QQ，还有更多如微信、wecom、Minecraft等等。 我认为最好要么逐一提及它们，要么不提及它们。

可以写支持的平台列表，也正好一目了然，什么平台提供什么样的支持级别，是需要自己Hack还是开箱即用，遇到问题了是不提供官方帮助（社区项目）还是官方提供帮助（官方支持），可以列一个表格

[shigma]

Koishi 用户群由官方授权管理，但主要开发者在用户群均没有任何话语权，因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的。

在没有 chronocat 的时代，绝大多数用户均使用 gocqhttp 插件对接 QQ，那个时候没有人说 QQ 怎么不开箱即用。怎么有了个 chronocat 然后 chronocat 消失以后，反倒有人认为不开箱即用了？

Koishi 的聊天平台支持策略自 4.0 起就从未发生过变化，无论是 gocqhttp 插件还是 chronocat 都是社区行为。Koishi 不支持 QQ，但 Koishi 官方支持 OneBot。QQ 一直由 OneBot 提供支持。由于直接写 OneBot 会让人迷惑，所以我采用了当前的写法。

如果你们觉得不妥，我觉得可以改成「支持 OneBot (QQ)」或者「支持 QQ (OneBot)」。

[MaikoTan]

在没有 chronocat 的时代，绝大多数用户均使用 gocqhttp 插件对接 QQ，那个时候没有人说 QQ 怎么不开箱即用。怎么有了个 chronocat 然后 chronocat 消失以后，反倒有人认为不开箱即用了？

There's a proverb from the ancient China: It is easy to go from frugality to extravagant, but difficult to go from extravagance to frugality.¯\(ツ)\/¯

中国古代有句谚语： 由俭入奢易，由奢入俭难。¯\(ツ)\/¯

[mzltest]

Koishi 用户群由官方授权管理，但主要开发者在用户群均没有任何话语权，因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的。

由官方授权管理，那么应该也是可以代表官方的（相当于有官方的背书，因为开发者没话语权的话为什么在文档里面写交流群，开发者也能直接编辑文档）。而且群号也写在了官方的文档里（https://koishi.chat/about/contact.html ） ，并没有“官方并不直接参与管理”或者"由社区提供支持"的相关描述。

另外，因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的。是否可以指代GitHub 的issue这种讨论渠道依然支持对QQ提供Support，仅仅是其他“开发者不参与管理”的渠道发生了割裂不再对QQ部署提供帮助？

在没有 chronocat 的时代，绝大多数用户均使用 gocqhttp 插件对接 QQ，那个时候没有人说 QQ 怎么不开箱即用。怎么有了个 chronocat 然后 chronocat 消失以后，反倒有人认为不开箱即用了？

开箱即用只是举例类比，我的意思是表明支持的平台以及提供的支持级别，是Support还是Ability，也就是说是不是由官方做Maintenance和Support，还是社区贡献者提供维护和支持

Koishi 的聊天平台支持策略自 4.0 起就从未发生过变化，无论是 gocqhttp 插件还是 chronocat 都是社区行为。Koishi 不支持 QQ，但 Koishi 官方支持 OneBot。QQ 一直由 OneBot 提供支持。由于直接写 OneBot 会让人迷惑，所以我采用了当前的写法。

如果你们觉得不妥，我觉得可以改成「支持 OneBot (QQ)」或者「支持 QQ (OneBot)」。

正如你描述的，Koishi不支持QQ，那么我说Readme里的Koishi支持QQ应该删去这句话没有问题，因为Readme与Policy存在冲突，这确实是一个doc issue。不存在因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的。

结合整个讨论背景的话，现在个人建议是把支持QQ改成支持Onebot协议(v11/v12)。明确说支持QQ的话很明显与您说的开发策略有冲突，更容易引起迷惑。

[shigma]

问题是你现在连onebot的相关帖子在论坛也一一删除，现在你官方就是不提供对qq对接的任何支持不是吗

论坛贴不是我删的，甚至也不是论坛的管理员删的。发送论坛贴的是普通用户。

官方对 QQ 的支持一如既往，没有发生任何变化。过去我们通过 OneBot 插件提供，现在也是。

[shigma]

而且在超时空猫猫发布后，官方曾说要取消对于onebot的相关支持，甚至使用超时空猫猫是教程里不可或缺的一部分。

所有官方插件都是 @koishijs 前缀的，而超时空猫猫是 @chronocat。在插件市场中，官方插件都有官方标识，而超时空猫猫没有。你怎么会认为代表官方？

[shigma]

你这样上不去下不来算哪门子支持

Koishi 是面向开发者的框架，GitHub 是面向开发者的社区。对比其他框架，我有充分理由说 Koishi 提供了足够的支持。

你所谓的不再支持只是因为过去用户群或者论坛提供了保姆级别的客服，而现在不提供了而已。Koishi 是一个机器人框架，这些客服本身就不属于 Koishi 的功能。

[shigma]

是否可以指代 GitHub 的 issue 这种讨论渠道依然支持对 QQ 提供 Support

Koishi 是一个机器人框架，我们当然会在其所声明的功能范围内提供支持。你在 Koishi 官方的仓库内能看到与许多 QQ 相关的 issue。比如 koishijs/koishi-plugin-gocqhttp 仓库里就有很多。

[shigma]

不存在「因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的」。

我愿意修改 readme 的前提是 readme 有问题，而不是用户群政策发生变化。

你提出的建议我已经考虑了，我上面就说了可以改成「支持 OneBot (QQ)」或者「支持 QQ (OneBot)」。

我反对的只是以用户群政策发生变化为理由，增加开发人员工作成本的行为。

[shigma]

由官方授权管理，那么应该也是可以代表官方的（相当于有官方的背书，因为开发者没话语权的话为什么在文档里面写交流群，开发者也能直接编辑文档）

即使不考虑提供 QQ 相关的教学，用户群也为大量普通 Koishi 用户提供了讯息资料和交流平台。作为 Koishi 生态中的一部分，官方将其收入「参与交流」一页中。这当然并不能代表用户群中的所有言论和行为都有官方背书。

[mzltest]

不存在「因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的」。

我愿意修改 readme 的前提是 readme 有问题，而不是用户群政策发生变化。

你提出的建议我已经考虑了，我上面就说了可以改成「支持 OneBot (QQ)」或者「支持 QQ (OneBot)」。

我反对的只是以用户群政策发生变化为理由，增加开发人员工作成本的行为。

这并不是

由官方授权管理，那么应该也是可以代表官方的（相当于有官方的背书，因为开发者没话语权的话为什么在文档里面写交流群，开发者也能直接编辑文档）

即使不考虑提供 QQ 相关的教学，用户群也为大量普通 Koishi 用户提供了讯息资料和交流平台。作为 Koishi 生态中的一部分，官方将其收入「参与交流」一页中。这当然并不能代表用户群中的所有言论和行为都有官方背书。

我同意您的部分观点。首先既然官方的文档里明确写了这些联系方式且您也称他为生态的一部分，说明官方至少是明确认识或者说允许其作为官方的一个延伸的（就像之前有一位成员提到的QQ频道，现在QQ频道的官方SDK都只是用户维护了，官方很少参与维护，那我们能说他现在是非官方SDK了吗）。我们当然不会讨论单个用户的行为，事实上，单个管理员的行为也与官方无关，这一点我不反对您的观点。（PS.我一直说的都是官方论坛，回复您与讨论群有关的消息是因为您主动提起讨论群而忽略了我说的是用户论坛，但这其实都是官方社区支持）。

但是，很明显在论坛的帖子来看，这些论坛的总体氛围都是排斥QQ部署的（之前举的很多帖子已经消失了，但是您作为项目的维护者应该有论坛的管理员权限，您应该可以看到相关的操作记录），相关问题会被锁定删帖，群里会被禁言踢出。您当然可以默许这些行为的出现，甚至即使您亲自下令怎么做，这也是您的自由（当然我也不关心，我只是希望提升文档的可读性和明确性）。但是作为一个被列在官方文档上的联系渠道，仍然建议您明确说明这些渠道完全由社区管理，否则您不应该在被询问时才明确撇清关系，因为如果不明确说明，以联系方式（contact）展现在官方材料自然就可以看做是官方的延伸。

这段打得不太通顺，希望您能理解

[shigma]

你该如何解释相关帖子的莫名消失，如果不是koishi官方以及相关论坛管理员，广泛的帖子会莫名其妙消失吗

相关帖子是同一个人发布的，也是同一个人自己删除的。论坛用户可以删除自己发布的帖子。

[shigma]

楼上的两位朋友可能有所误解，我现在重新解释下用户群和论坛的由来。也跟你们说说真心话。

目前各大主流平台,包括知乎等都在说koishi支持qq,可以部署qq机器人,但是很多用户求助后才知道交流群和官方都不支持qq群,因此我觉得这个是有误导性的.

知乎的专栏就是我本人写的。事实是，我在写知乎专栏的时候根本不存在用户群、开发群、论坛。那个时候的 Koishi 用户全部都能只看文档就完成 QQ 和其他聊天平台的接入。我当然不是说这一届用户不行了，毕竟现在的接入难度确实有所提升。我只是说在几年前，没有用户群和论坛的时候，没有人质疑 Koishi 接入 QQ 的能力，现在 Koishi 发展得越来越完善，大家却反而开始质疑，这是我非常难以接受的事情。

[mzltest]

不存在「因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的」。

我愿意修改 readme 的前提是 readme 有问题，而不是用户群政策发生变化。

你提出的建议我已经考虑了，我上面就说了可以改成「支持 OneBot (QQ)」或者「支持 QQ (OneBot)」。

我反对的只是以用户群政策发生变化为理由，增加开发人员工作成本的行为。

这并不是我的理由和原因，我的原因一直都是Readme支持QQ的描述与目前的现状不符，您刚才也出面确认了koishi官方并不支持QQ协议。我最开始的角度是QQ部署不会得到官方支持，因此应该从官方Readme中删去。我并未加入用户群，但是即使“用户群政策发生变化”，这也是官方不支持QQ协议的现状的体现之一。您可以说我的证据不充分，但我认为您不能说我的行为是“以用户群政策发生变化为理由，增加开发人员工作成本的行为。”，事实上，我原帖中第三个例子引用的是一名版主或管理员的话，明确说明koishi不支持QQ协议，这也是目前官方的支持状态。

关于修改的问题，我个人建议强化onebot，弱化QQ，因为如果强化到QQ上与目前的政策依然是冲突的。您可以说支持QQ，但是这个支持是通过onebot适配器支持的，并不是原生支持的（例如支持QQ那段后面的Telegram Discord等），我希望能够强化这一点。

我个人偏向于Onebot(QQ等适配该标准的应用)这个表述，但我更建议使用表格等形式建立一个速查表，这样也不用前往文档页来找哪个平台用哪个适配器了，节省一步操作。

例如：

平台|适配器|提供者|支持状态

telegram|xxxxxxx|xxxxxx|官方支持（contact页或issue链接） qq|xxxxxxx|xxxxx|社区支持(对应issue链接）

[shigma]

我本人一直比较排斥非 GitHub 形式的社区交流。Koishi 在 v1 时期（四年前）有过一个官方的交流群，不过因为一些变故被我自己解散了。在此之后的几年内我完全没有建立任何交流渠道，而大家在 GitHub 和 Discord 的交流体验也非常好。我认为 Koishi 没有官方群也能非常顺利地继续下去。

在这种情况下，Koishi v4 发布后，一位朋友向我提出能不能建立官方群。我当然是反对的。然后他进一步说我可以完全不用花费精力管理。我觉得这没问题，便同意了。这位朋友现在就是用户群的群主。在我看来，他和他的用户群确实给我减轻了一些负担。而用户群用创立开始的政策便是严苛的群规。因为没有参与在内，我没有资格评价这些事情（不然用户群的维护就变成我的责任了)。

[shigma]

再怎么有能力也不是你删除控评的理由，你现在的情况就是删除了论坛有关于onebot与超时空猫猫适配器所有有关的内容，这不可能是所有使用适配器对接qq平台的用户的一致行为，而且即使超时空猫猫适配器不属于官方范畴，onebot适配器的相关教程也不需要删除

我连群都不看哪来的精力删帖……你不信就不信吧，跑到 GitHub 造什么谣。

[mzltest]

我本人一直比较排斥非 GitHub 形式的社区交流。Koishi 在 v1 时期（四年前）有过一个官方的交流群，不过因为一些变故被我自己解散了。在此之后的几年内我完全没有建立任何交流渠道，而大家在 GitHub 和 Discord 的交流体验也非常好。我认为 Koishi 没有官方群也能非常顺利地继续下去。

在这种情况下，Koishi v4 发布后，一位朋友向我提出能不能建立官方群。我当然是反对的。然后他进一步说我可以完全不用花费精力管理。我觉得这没问题，便同意了。这位朋友现在就是用户群的群主。在我看来，他和他的用户群确实给我减轻了一些负担。而用户群用创立开始的政策便是严苛的群规。因为没有参与在内，我没有资格评价这些事情（不然用户群的维护就变成我的责任了)。

我并不反对严苛的群规（离题：之前搞了个答题获取身份组，专门防伸手党），我的意思是，如果您不能参与这些渠道的管理，您应该在官方文档中明确描述为 用户建立的交流社区 ，这样即使那些渠道发生什么，甚至逐个踢出，都与koishi官方无关。也就是说，如果您不能承担它作为官方的延伸，那么您就需要明确说明跟它的关系。

[shigma]

既然官方的文档里明确写了这些联系方式且您也称他为生态的一部分，说明官方至少是明确认识或者说允许其作为官方的一个延伸的

关于这个问题其实非常好解释。

我们现在假设我们从官方文档中删除任何与用户群或者论坛相关的信息。那么会有非常多的用户被迫跑到 GitHub 或者开发群里发言询问登录问题、安装问题、网络问题。这些问题当然都不应该在 GitHub 或者开发群讨论。结果就是对于每一个问题我们要么关掉，要么告诉提问者「去 xxx 群里或者论坛问吧」。从结果是用户群和论坛仍然是存在的，并且依然被引流了。但是移除这些信息会导致 GitHub 和开发群每日的无关信息量大幅增加，严重影响 Koishi 的开发。

[shigma]

平台|适配器|提供者|支持状态

如果您不能参与这些渠道的管理，您应该在官方文档中明确描述为 用户建立的交流社区

我很快就会对 readme 和文档进行修订。

[shigma]

我只是说明论坛存在相关现象

那现在我了解情况了，不过我无法做出对应。我只能说如果有开发问题，欢迎来 GitHub 或者开发群提问。

[mzltest]

平台|适配器|提供者|支持状态

如果您不能参与这些渠道的管理，您应该在官方文档中明确描述为 用户建立的交流社区

我很快就会对 readme 和文档进行修订。

感谢您的理解。由于我不会用GitHub除了issue外的其他任何功能，恕无法提供PR，还请谅解。

[shigma]

至于所谓 308 问题，如果不明确的话我也统一澄清：

• 308 说用户群不能讨论 Docker，Koishi 是支持的
• 308 说用户群不能讨论开发问题，Koishi 也是支持的
• 同理，308 说用户群不能讨论腾讯软件的对接，Koishi 是可以做到的

308 问题不由 Koishi 开发者决定，不对 Koishi 的规划和政策产生影响。如果你想讨论这些问题，可以自行建立其他交流群。如果产生了良好的交流氛围，可以告诉我，我去官方文档上把你的群号也列进去。

[flpqnws]

Koishi 用户群由官方授权管理，但主要开发者在用户群均没有任何话语权，因为用户群的政策发生变化而导致用户向官方仓库提出改动我认为是非常不合理的。

在没有 chronocat 的时代，绝大多数用户均使用 gocqhttp 插件对接 QQ，那个时候没有人说 QQ 怎么不开箱即用。怎么有了个 chronocat 然后 chronocat 消失以后，反倒有人认为不开箱即用了？

Koishi 的聊天平台支持策略自 4.0 起就从未发生过变化，无论是 gocqhttp 插件还是 chronocat 都是社区行为。Koishi 不支持 QQ，但 Koishi 官方支持 OneBot。QQ 一直由 OneBot 提供支持。由于直接写 OneBot 会让人迷惑，所以我采用了当前的写法。

如果你们觉得不妥，我觉得可以改成「支持 OneBot (QQ)」或者「支持 QQ (OneBot)」。

我觉得这句话中无论是 gocqhttp 插件还是 chronocat 都是社区行为是否有误？该怎么解释 https://github.com/koishijs/koishi-plugin-gocqhttp 这个仓库呢？当然如果 https://github.com/koishijs 这个账号不算官方账号的话当我没说

[shigma]

gocqhttp 是我维护的社区插件。@koishijs 组织下都是官方开发者维护的插件。你可以理解成介于官方和社区之前，或者属于合作性质。

chronocat 是一个纯粹的社区插件。我连源码都没见过（我当然能看到，但是没参与开发）。

[ConstasJ]

简而言之，Koishi.js官方支持OneBot v11协议（有官方适配器），一般而言的“支持QQ”指通过onebot适配器+go-cqhttp等支持onebot v11协议的QQ机器人软件与QQ平台进行对接。由于腾讯官方从来没有发布过QQ本体（频道以外的QQ聊天）的机器人API，所以Koishi.js无法为接入QQ群提供官方支持。

基于QQ频道官方API的QQ频道适配器@koishijs/plugin-adapter-qqguild倒是可以认为是官方支持。

go-cqhttp插件算是官方开发者参与维护的社区插件（以koishi-plugin开头而不是@koishijs/plugin），而chronocat和koishi官方毫无关系，如shigma老师所言。

个人觉得现在的说法确实有点让人误解（准确性和易于理解性有的时候确实是鱼与熊掌的关系），如果表述为“支持Onebot v11协议（该协议可通过go-cqhttp/mirai onebot对接QQ）”应该会好一些。

顺带一提，用户群不能讨论倒是可以用“怕被tx盯上”解释，论坛删帖是几个意思？但是，我还是觉得这个问题不应该放在这里讨论。

[shigma]

我就一破写代码的，要不是有这个 issue 我都不知道论坛删帖这回事（摊手

[Lipraty]

我不支持因为这种毫无营养的事情就修改 Readme。

关于 QQ ：从内容上说，QQ 频道是 QQ 这个即时通讯软件功能之一，说 QQ 有什么不可以？截至目前（2023-08-10）频道唯一入口依旧是 QQ 各平台客户端； 关于 OneBot(V11): onebot(v11) 是官方开发并支持的协议插件，并且我认为支持范围仅限于协议或插件本身，任何协议实现端应由各实现端自行负责； 关于连接 QQ 本体：其他社区中出现的例如 chronocat 等社区项目理应由其社区自行维护，而不是在这个地方浪费 Koishi 开发者精力； 关于用户群：该群与开发群及管理人员毫无交集，shigme 等主要开发人员也并未参与管理和维护； 关于论坛知名的「308 贴」：这是针对用户群而建立，请打开 链接 并阅读其中第一句话：

Koishi 的一些使用方式不被用户交流群所支持

关于论坛删评/控评：请举证说明，而不是在这里造谣。

[ConstasJ]

我不支持因为这种毫无营养的事情就修改 Readme。 关于 QQ ：从内容上说，QQ 频道是 QQ 这个即时通讯软件功能之一，说 QQ 有什么不可以？截至目前（2023-08-10）频道唯一入口依旧是 QQ 各平台客户端； 关于 OneBot(V11): onebot(v11) 是官方开发并支持的协议插件，并且我认为支持范围仅限于协议或插件本身，任何协议实现端应由各实现端自行负责； 关于连接 QQ 本体：其他社区中出现的例如 chronocat 等社区项目理应由其社区自行维护，而不是在这个地方浪费 Koishi 开发者精力； 关于用户群：该群与开发群及管理人员毫无交集，shigme 等主要开发人员也并未参与管理和维护； 关于论坛知名的「308 贴」：这是针对用户群而建立，请打开 链接 并阅读其中第一句话：

Koishi 的一些使用方式不被用户交流群所支持

关于论坛删评/控评：请举证说明，而不是在这里造谣。

第一，情况真实存在，你可以通过搜索栏搜索发现有关于对接qq平台的所有内容包括onebot全部删除，我不相信这不是人为所致，并且在koishi论坛右上的聊天频道中“Sy3124”用户提及自己发帖被删除 第二，作为广泛宣传的read me大多数人对于宣传做出的判断是与qq直接进行对接而不是所谓的qq频道 第三，如果第一点成立，那么github是唯一能够向官方反映问题的地方，不可能作为一个用户在开发者群大肆反映此类问题 第四，用户群内大问题是否与本人有关并非在讨论范围内，read me提及了自己能够对接qq平台，这是问题的关键。是否对read me进行修改才是我们应该讨论的问题

请直接举出证据（如截图）

[shigma]

那么github是唯一能够向官方反映问题的地方

所以 Koishi 有什么问题？我没有看你反映问题啊。只看到你开了个小号在这里造谣。大号呢？

[shigma]

readme 已更新，此 issue 关闭。

[Lipraty]

欸，挺抽象的