只有点赞会有通知，私信发出去对方也都收不到
我的也是一样的
看下设置 你的权限都是正常的 
就这一个界面，你那权限我是普通用户没有对应设置的地方
所以尽量是在github提issue吗
抱歉，给你带来了这么不好的体验。
关于这个 github issue，我是有一些情绪的回复。原因是我觉得沟通交流，应该是建立在相互平等的角色。
首先，反馈问题，竟可能详细的描述问题，而不是一句话“这里应该是 any”。
其次，引擎维护者并不是每个人对每个系统都非常了解透彻。当分配到某个模块某个任务，并不是当前处理这个 issue 的同学就对当前模块或者系统非常了解。当对当前系统并不完全了解的情况下，我们可能会多问一些情况，因为有时候复现环境问题会导致差异。而这个 issue 得到的回复却是「趾高气昂」「高高在上」：
我想我的姿态也算是摆得特别低了吧? 帖子中也贴了 issue 地址，每条回复也都没有编辑过，既然也都甩到论坛上了，那么也欢迎大家去围观。
当然，在这个世界上，一个人也不可能做到让每个人满意。如果你觉得我高傲，那么就是吧，我没啥好反驳的。
是的，我承认我对 ts 这门蹩脚的语言并没有了解透彻（我之前的工作主要在处理原生相关的模块）。
由于刚接管这个脚本相关模块，也不清楚新建出来的工程是 ‘strict’: false 的情况，因此，跟进此 issue 的时候，我也先尝试写了几行代码复现问题，这也是正常的复现问题的流程，但是并无法复现出开发者反馈的问题，ts compiler 并没有报错，eslint 也没有错误，因此就继续在 github 上与开发者交流。但是得到的却是开发者的各种冷嘲热讽、不耐烦和自以为是的言语。
另外，脚本系统相关的 issue 近 200 个，这是一个深不见底、牵一发动全身的底层模块，处理起来相对会比较谨慎，新人开始维护也需要一些时间了解透彻，和尝试还之前的债（背起锅）。
接起这个锅，请给我一些时间。如果没有及时回复，让你觉得是傲慢的话。那么这里抱歉了。
其实，可以搜索我账号 dumganhar 关联的中文论坛、英文论坛、github 的所有回复，如果有你觉得傲慢的任何回复，那么我先道歉、道歉、再道歉。
https://forum.cocos.org/u/dumganhar/summary
https://discuss.cocos2d-x.org/u/dumganhar/messages
https://github.com/cocos2d/cocos2d-x/pulls?q=is%3Apr+author%3Adumganhar+is%3Aclosed
说实话，回复这个帖，我知道我会被怼死，因为我并不是一个擅长与人争辩的人。
最后，关于 loose 模式文档的事情。我的想法是做更好，需要细化，因为大部分情况下开启 loose 是对 性能有好处的，而某些时候, 比如对 … 的处理，的确会导致行为上不符合预期，这里应该针对一些行为上容易导致异常的选项，开放出子 loose 选项来让用户选择，而这子 loose 选项 默认关闭。平时琐碎的事情的确比较多，没有及时更新文档。其实，作为开源引擎，我们也希望开发者能够尽可能参与进来，我们的文档也是开放的，也欢迎开发者贡献对应的文档改进：https://github.com/cocos/cocos-docs 。
1赞
提示保错 运行不报错吧?
其实不用太在意，因为可能仅仅是刚好他那天心情不太好
抱歉当时语气太激动，帖子里其实说的是一直以来反馈问题官方给人的感觉
ts 是蹩脚的脚本语言的话，你觉得如果情况允许，不考虑生态之类的问题，什么脚本语言最好？
1赞
专职跟轮岗，差异就在这里。想要一个模块能够有很高的专业度，必然就需要有强力的人专职在一件事情上。
问题是今天哪个公司不是一波一波换人，一波一波调整架构，一个坑还没捂热就得去填新的坑。
作为脚本系统的上级管理者（不是我），也很难取舍，团队里强力的人就那么几个，你是希望他们多去做新功能，不断换新人来填老坑？还是希望他们就不断折腾老坑，把新功能留给新人去挖出更大的坑？
互相理解一下吧。
1赞
层面 位置 角度 出发点不同 还是尽量多点理解吧
就算是一个项目组在做同一个游戏的一批人 程策美都要经常打架 从制作人主策到运营客服 更别说还有玩家 玩家反馈问题到运营客服再到研发 也是会觉得官方态度怎么傲慢 不能真正理解 那就多点包容吧
俺的也一样！
ts是蹩脚的语言 这句话有点像我前几天面试听到的。
我们用cocos做了个台球 在低端机上很卡一个多月了没解决。问我有什么建议… 。我说你如果确定是cocos问题就赶紧换引擎。但是在质疑cocos之前 麻烦你看看是不是自己问题。
这段经历也合适给cocos这位研发人员（虽然不是他选型的）
主要问题是cocos的团队不怎么懂前端吧，如果懂的话 估计 npm、webpack、ts什么的就都能正常用了
1赞
我在想为什么不改成lua或者c#么，选择ts/js这个之前游戏都怎么涉及过的脚本领域，导致其他引擎/语言现成的轮子无法直接使用。现在unity的c#不也有hybridclr，甚至.net现在版本也可以直接aot了。
我在想如果换成c#，好多unity的东西可以直接拿来用。ts感觉也只适合单系统下的开发，项目工程上去了，多系统之间的封装完全不如c#灵活。
因为web和小游戏 跑不了c#啊
现在wasm了，这都不是事
ts/js 在小游戏上是原生支持的，wasm还要再跑一次虚拟机，就是类似浏览器->js引擎->c# 虚拟机 -> c# 代码，多个中间层效率上不高。
另外ts/js的基础设施/轮子也是非常多，如果考虑到npm的库社区的话，可能比c#的nuget还要多。
lua 的库才是非常少的。
github 提交的 issue 确实是需要更详细一点描述，保证双方都的理解和环境是在同一层面。我也经常会要开发者提供 demo。这么做不是说我自己没法做个 demo，而是我做的 demo 和描述的 issue 可能理解的就不是一样。这个区别可能是很细微，但是会浪费双方很多的沟通成本。
@dumganhar 是引擎的老员工了，做事情非常踏实认真。他这么问就是想把 issue 给重现出来而已。而且他还因为查这个问题，把 tween 模块（这个模块不是他负责的）的一系列问题都看了一遍，花费了一个多星期时间。我们还担心会有兼容性问题，而在论坛发帖说明这个情况。
引擎确实是有很多问题，我们的能力也确实有限，但是我们的态度是没有问题的。大家都是技术人员，讨论问题尽量摆事实讲道理，不要带着感情，这样不利于问题的解决。就如 @jare 说的，大家都互相理解吧。三人行必有我师嘛。引擎人员在某些方面不如开发者，这不是很正常的事情吗？
9赞
js/ts的库大多是web前端库，不适合游戏