我给你上报下好了，我也不是很清楚

这个问题我老早就反馈了吧，还没处理？我现在一直都是用的控制中心的。。。

麻烦了

但作为一个linux使用者, 一般都是使用终端命令比较多嘛. 图形界面不是linux的核心

这个问题我已经反馈给我们老大了，看他是怎么说。

好的, 麻烦了

为什么总是反馈给“老大”？难道不应该是反馈给“开发者”或者“开发团队”？Deepin做决策都是一个人拍板的么？我觉得这个问题也就只是一个bug，或者算是个feature request吧，至于要反馈给“老大”么？那我要怀疑Deepin内部开发的效率了。

楼上扯得远了点，你对他们团队的结构和合作方式了解吗？反馈给老大也可以是一个先收集然后共同讨论的过程，话说哪里可以看出“总是”，我整天盯着论坛也没发现几句，最多的是“已经记录”这一句。

资历较深的人先过目不是一种很好的方式吗？也许他们老大就是负责这个模块的。

所以说，文字只是片面的，如果你对他们的协作方式确实十分了解，那么你确实可以依据事实提出意见和建议，而不是从只言片语中就轻易推得整个情形。或者如果你在论坛有任何的亲身经历，你也应该直接吐露，争取积极交流，互相理解。

因为这是最近几天里我第二次看到这个说法了，另一次是在Deepin Terminal的帖子里说的，他还说了“这个小弟我做不了主”，从这句话来看，做主的不是一个团队，而是老大。而且这也不是“先过目”这么简单了。

我觉得一般公司采集用户反馈和处理的流程大概是这样的。

客服（或者叫接口人吧），从外部采集用户反馈（可以有许多途径，包括但不限于论坛、bugtracker、qq、邮件列表等等），将该反馈提交到内部相关的开发团队处，内部应该有自己的一套项目管理工具，在内部开发者会使用这个管理工具来跟踪这个事情，开发者可能会讨论（以各种形式，比如开会、IM简单讨论，或者某人直接拍板等等）。而接口人则可以通过这个内部的管理工具了解到这个问题的状态，并向用户反馈。

可见，用户反馈应该是提交到内部的项目管理平台上，然后由有关开发人员来处理（处理包括：不采纳建议、采纳建议但不立即修复/实现、立即修复/实现等等）。如果所有问题都是提交给一个人（不管是不是老大），而不是提交给一个平台，那这样的团队管理就太乱了，这个人也会成为瓶颈。

我想你是误会了，首先那个反馈给一个人的答复，确实不是一个规范的流程，但那句“老大”也许只是他们团队里的一个“爱称”，没有叫leader就已经说明这个团队比较和谐了，不太可能存在一个人拍板的情况。他们的团队工具是tower，但我也了解到tower的团队是有一个主账号的，可能是他们老大主导建立这个账号并管理的，所以向这个账号汇集也可能会随意脱口为向老大报告了。也可能是这位是他们老大的助理加学徒，但如果消息到了王勇那里，他也不会自己随意决断的。

“这个小的做不了主”也只是一个比较幽默的话，因为他一个人确实住不了主，不能忽视整个团队的意见。就我所知，他们是有固定的时间一起研讨bug的（没记错的话是每星期三下午），情形没有你想的那么严重、不规范。（说漏了，deepin终端是他们老大的作品，所以这个必须向他们老大汇报 :? ）

应该说，可以向他们建议，每一位队员都要有自己的创见性，发挥每一个人的主观能动性，但这只言片语我无法推出他们缺少这个。（毕竟不太了解他们的事情，我也不好唐突插嘴）

我插个楼

dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Suspend boolean:true

login1是systemd提供的标准服务，deepin使用此作为会话管理的部分模块。　　
不能直接操作suspend或者直接操作/sys是因为过于底层，导致DE没有足够时间处理相关事情。
而systemd是有提供一套inhibitor机制。　典型的用处比如，刻录机正在辛苦的工作，这时候即使用户要关机、休眠也应该阻止用户。

歪楼太严重，前面的老大没有明确指名

我们流程是：
收集问题
QA验证问题
能重现的直接给对应的开发者（或者产品经理）/不能重现的继续找原因或者直接给开发者看看
开发者修复问题
QA验证修复
对外推更新

以上很多细节没说。目前我也没见过那个公司的流畅是一成不变的。