深度这边更新机制不健全

[chuxinyuan]

https://www.deepin.org/zh/original/deepin-music/

这个页面都多年不更新了，不知道是谁在负责。之前提到深度音乐改进的建议，开发人员是和稀泥水平真的一流，活一直不干，这简直是混日子等死的节奏？

[chuxinyuan]

另外请你们统计下每个问题，计算下平均响应时间和已解决问题的占总问题的比例。

[chuxinyuan]

另外，有的问题虽然优先级不高，但是很容易解决，顺手就能解决的，不会影响 v23 release 进度的。

[c61292558]

既然很容易解决，为什么你不提交一下pr代码？

[chuxinyuan]

@c61292558 这样仅仅解决了一个问题，版本不停的在更新，需要从流程化、标准化和自动化上下手，解决机制问题。事实上我之前也是考虑过提交 PR 的，奈何那个深度音乐丑出了边际，所以我首先提了一个 关于 deepin-music UI 美化建议 结果一直没有人响应。自从 Gnome 更新到 45 后我就压根没有在 Manjaro 系统上安装成功过深度音乐。

[BLumia]

这样仅仅解决了一个问题，版本不停的在更新...

有 PR 建议提。合入进去的提交除非有特殊原因，否则是不会回退的。

[c61292558]

先功能后ui，先把功能做好或者bug修好再调UI的道理你不懂？你提了pr难道后面就不能调UI了吗？

[chuxinyuan]

另外，我建议你们向 cutefishOS 项目学习，看看人家的审美水平和响应速度。

[c61292558]

响应速度快并不等于系统能用，cutefish连deepin目前的可用性都做不到

[BLumia]

开发人员是和稀泥水平真的一流

主要这个页面不是我（或者说我们研发人员）在维护，所以我们也更新不了。以及我们研发目前都在修 v23 的各种问题来确保 v23 能顺利发出去。。。这个页面的事情，节后我再催一下运营那边吧。

这个页面都多年不更新了，不知道是谁在负责。

@myml 之前我有过一个 proposal，希望我们自己的应用去适配 AppStream spec，然后这些页面可以直接适应 AppStream 的信息来生成。这样可以保证：

1. 可以自动化更新这些信息
2. 同时确保这些信息可翻译
3. 确保支持 AppStream 的其它位置（或者说其原本的预期场景，即应用商店）也可以使用相同的信息做出呈现

考虑到 v23 发布之前会持续很忙，这个要不我在 v23 release 后推进一下？或者由其他人员推进下？

[chuxinyuan]

主要这个页面不是我（或者说我们研发人员）在维护

当时不是艾特相关人员了吗？你看看他回复一句了没有？所以他是看到了故意装睡还是压根没有看到？提出问题了难道不是先响应一下吗？然后慢慢解决都行，你们这是压根不响应啊，根本看不到解决的希望。

[BLumia]

当时不是艾特相关人员了吗？

是的，甚至我跑那位工位上沟通去了（也提出了 AppStream 的那个提议），进行了一些简单讨论。我感觉有可能是因为有过讨论所以那位忘掉了答复 😂

当然，我们目前每天都有很多 GitHub notifications（比如我自己目前就有 ~900 个）消息，处理过程中如果有遗漏，我觉得也是可以理解的事情。

开发人员是和稀泥水平真的一流

提及的对方未做出答复而对我做出“和稀泥”评价，恕我不能认可。

当然，作为澄清，我本身也没有试图“和稀泥”。即便在假期也做出回复是因为我本身也作为“贡献者”而非“员工”存在，也是希望 deepin 社区能展开更有意义的讨论的。指出问题也是向着解决问题迈进，我仍然抱着尽可能推进问题的解决的目的做此（以及下面另外单独回复的那个）答复。

同为贡献者，大家之间是平等的，我们谁也不欠谁什么东西。希望你也可以站在共建社区的贡献者的角度参与后续讨论。

[chuxinyuan]

@BLumia 这个评价给到深度员工，没说你啊，我说的是我手动 Mark as the best answer 的那位。其实我对你还是比较认可的，比较积极主动的和用户沟通，耐心回复用户的每个问题，你比他们更像深度员工。

银行每天那么多交易数据也没说谁的存款给漏了，如果重视起来，每个问题放在数据库里，逐个解决，不可能漏掉的。本质上还是机制问题。

我作为一个普通“冰箱”用户，没时间精力，也没能力下场“制冷”，但是评价“冰箱”制冷效果并无不妥。Deepin OS 代表着国产操作系统的希望，绝对不能这样拉跨，爱之深，责之切。

[BLumia]

这个评价给到深度员工

抱歉，为了避免混淆，作为澄清：我也确实是员工，只是非工作时间还是会以普通贡献者的身份参与社区讨论（这本身不是工作范围内要求的）。当然我也确实认为我们在这方面做的不够好。

每个问题放在数据库里，逐个解决，不可能漏掉的。

我们确实有在处理问题，但其实观察一段时间就会发现，只要存在新特性的迭代开发，那么问题数量就不会是仅仅单纯的减少。这有点类似一边放水一边接水，水就不会有那么容易放完的情况。同时，也是因为近似的原因，才会有优先级的标注（因为短期内确实是修不完的）。

i.e. 我们知道存在很多问题，只是目前在优先处理的全是被认为 RC/正式版 必解的问题。

我作为一个普通“冰箱”用户，没时间精力，也没能力下场“制冷”，但是评价“冰箱”制冷效果并无不妥。

认同这一点，但我觉得还是存在一些差异。你是冰箱的消费者、冰箱厂商的客户，而对于 deepin 而言，则是 deepin 社区的参与者而非消费者。角度是有细微的差别的。

回归正题的讨论就发到另一个回复下吧 :)

[BLumia]

看你还是蛮关注 deepin 社区的，但又不是特别的关注。如果你有更多兴趣的话，我建议你加入我们的 Telegram 或 Matrix 聊天室，有一些问题的讨论上会更方便，甚至包括催一些问题的进度（（

其实你的评论颇有一些纸上谈兵的意思在里面。我在这里统一答复下你几个新回复里提到的点吧。

我没有看到你们给每个 issue 分类以及设置优先级的标签啊？

我们有在使用一个单独的平台来聚合统计 developer-center 的 issue 状态，并根据优先级处理问题。其中由 QA 提出的问题，优先级直接体现在了标题上。由非 QA 提出的则需要 triage 后才会优先在聚合平台内标注，然后视情况同步到 Issue 标签上。当然这个平台目前只有 UnionTech 员工看得到。

先把历史版本的问题都解决了再开发下一个版本不好吗？

“都”解决是不见得现实的，你可以瞅一眼 developer-center 目前有多少 Issue。如果你真的对软件开发生命周期的实践操作感兴趣的话，建议参阅一些软件工程相关的书籍或者资料。当然虽说我这么回答是站在 DDE 整个项目视角而言而不是应用项目视角而言的，但这个事情本身也可以适用到应用项目上。

但是很容易解决，顺手就能解决的

我们非常欢迎 PR，并且只要 PR 质量过关没问题的话，无论项目是否是开源社区中心维护，我本人都承诺我会帮你推进 PR 的合入。

所以我首先提了一个 关于 deepin-music UI 美化建议 结果一直没有人响应。

https://github.com/orgs/linuxdeepin/discussions/5789#discussioncomment-7235772 我看 PM 响应过呀，怎么叫没有人响应呢？

我之前也说过，UI 建议这种内容是见仁见智的，并不是说有人提就一定会改。就其它项目（比如启动器和 dock）的情况而言，即便我们目前没有那么频繁的调整 UI，每次调整仍然是调整满足了一波人的需求，但也使另一波原本满意的人不再满意了。所以尤其是这类很主观的反馈，我们能做的只能是先记录，然后由设计人员决定到底改不改，以及什么时候改。

自从 Gnome 更新到 45 后我就压根没有在 Manjaro 系统上安装成功过深度音乐。

这里其实涉及到三点问题：

1. DDE 系列应用是首要确保 DDE 环境下的使用的。GNOME 或者别的环境 QA 是没主动测过的。
2. 我们不维护 Manjaro 的软件包。由于 Manjaro 主动故意延迟一段时间更新软件包，所以很多 dtk 与 DDE 的问题都是我们修过但是 Manjaro 仍然存在的。这点上我们建议尝试在 Arch 上看看能否复现。
3. deepin 第一方的 QA 只确保 deepin 发行版（以及 UOS）上的场景。不过我们其实有向其它发行版移植的 SIG（我也在对应的 SIG 里面），但移植 SIG 也只能覆盖到此 SIG 成员们自己所用的发行版和桌面环境。

所以这个问题上，我的建议是，先尝试 Arch 上是否也存在，是的话，开 issue。

[chuxinyuan]

其实你的评论颇有一些纸上谈兵的意思在里面。

我只是普通用户，只能管中窥豹，甚至我登陆 GitHub 都很难。不要期望用户做更多“制冷”的工作。

“都”解决是不见得现实的……

issue 的个数是有限的，实在无法解决的不解决，目标是让 issue 的个数变成 0。我就不明白，干嘛着急发行新版本，用户不是很在意新不新，稳不稳更重要。当然我可能是从滚动发行的角度在思考这个问题。

我们非常欢迎 PR，并且只要 PR 质量过关没问题的话，无论项目是否是开源社区中心维护，我本人都承诺我会帮你推进 PR 的合入。

我说的是方法论问题，三个维度，一是轻重，二是缓急，三是难易。我是说易在难之前，这个你应该不会有意见吧？不要一上来就你行你上啊这样的思维模式，逻辑上站不住脚，评价个冰箱还得会制冷不成？

https://github.com/orgs/linuxdeepin/discussions/5789#discussioncomment-7235772 我看 PM 响应过呀，怎么叫没有人响应呢？

在我看来这个只能叫响，而没有应。如果你说响应了，那也算吧！我更想表达的意思是把这个问题给解决掉。

我之前也说过，UI 建议这种内容是见仁见智的……

审美问题确实存在仁者见仁问题，不像真理问题，但是美女和丑女的标准也还是有章可循的，再不济搞个投票，或者参考市场上流行的那几个音乐播放器的 UI 也行啊

Manjaro Gnome 环境能否运行你们的软件，这个确实和你们没太多关系。但是格局有大，要有大胸怀大气魄，要有深度出品必输精品的 geek 精神，如果深度开发的软件能在更多的 Linux 发行版上运行，深度的知名度和美誉度也会加分不少。

---

回到主题，健全更新机制问题。

[BLumia]

不要期望用户做更多“制冷”的工作。

这个放心，没有这种期望，只是说实际软件工程的实践比你想象的复杂 😂

issue 的个数是有限的，实在无法解决的不解决，目标是让 issue 的个数变成 0

这个目标没你想象的那么容易，真的 :)

我就不明白，干嘛着急发行新版本

我这么说你可能会更容易理解：这其实 不完全是 一个 技术 问题。这里的版本发布时间有一些其它的因素掺在里面，由于涉及到一些暂时不可公开的商业版本相关的信息，所以我就不在此详细阐述了。

我说的是方法论问题，三个维度，... 我是说易在难之前，这个你应该不会有意见吧？不要一上来就你行你上啊这样的思维模式

这点我没意见，但于此同时你也就不能做出 虽然优先级不高，但是很容易解决，顺手就能解决 的评价了。如果你认为是顺手就可以解决，那么我们非常建议你顺手解决。如果你不打算的话，你认为的顺手不见得是别人认为的顺手，因此不能做出这样的评价。

在我看来这个只能叫响，而没有应。如果你说响应了，那也算吧！我更想表达的意思是把这个问题给解决掉。

“响应” 这个词本身就只表示有答复而不能表示解决的。以及，和之前提到过的一样，这类很主观的问题往往不会看到一两个反馈就做出调整。

还拿之前提到的 dock 举例，v23 beta3 与 v23 rc 内测版的 dock 变化巨大，就已经有听到“大好评”和“无法接受”的两种声音了，两者无论好坏的评价我认为都是主观评价，UI 与 UX 本身注定就不是一套方案能满足所有人的，而 DDE 与 deepin 应用的 UI 与 UX 则是收到反馈后，由 PM 与设计人员讨论后最终决定是否做出调整。

当然官网图片陈旧是另一回事，我目前能做的大概只是再催一下 🤣

审美问题确实存在仁者见仁问题，不像真理问题，但是美女和丑女的标准也还是有章可循的

不不不，“美女和丑女”的美丑就是由审美决定的，比如有人喜欢大胸有人喜欢平胸，何为标准？

Manjaro Gnome 环境能否运行你们的软件，这个确实和你们没太多关系。但是格局有大，要有大胸怀大气魄，要有深度出品必输精品的 geek 精神，如果深度开发的软件能在更多的 Linux 发行版上运行，深度的知名度和美誉度也会加分不少。

完全认同。这也是我们组建移植相关的 SIG 的初衷，和不同发行版的打包人员一同解决各类兼容问题。只是这个过程必然会是持续的。

---

回到主题，健全更新机制问题。

其实即便没这个帖子，我也已经在推进各个项目逐步提供 AppStream 支持了（例如公开的社区周分享会以及内部的一些讨论我都会提，并且目前也是有一些进展的），只是这个推进过程出于各种原因有些缓慢。长远而言，我计划按 https://github.com/orgs/linuxdeepin/discussions/8364#discussioncomment-9294936 这里提到的方案进行推进，而目前则需要我主动解决另一些（会阻塞推进的）问题，例如 AppStream 相关工具的新版本打包与进仓等，提供一些自动化工具，然后可能也需要做一些宣讲来让各个项目组可以更轻松的去提供支持。

当然，短期方案还是让运营人员去直接更新图片就是了 😂