好的写作，我在下面分享了一些关于这些问题的想法和历史，但主要结论是，根据我的看法，上述建议都是好主意。

1. 这是在没有安装技能的情况下发生的，还是总是这样？如果技能已经安装但在发送初始化消息之前没有加载，那么load_new_skills()方法中存在一些错误。

2. 这是去年夏天讨论的预期行为。在此之前，我们有一个“两周检查”(我认为这是一个检查所有默认技能是否已安装的过程),如果在过去两周内没有进行更新，我们将在加载技能之前触发更新。

我个人认为我们可以采取一种组合方法。对于所有默认技能的检查可能会导致阻塞技能更新，而两周检查可能(在mark-1/2设备上显示屏幕上的消息)在第一次加载后检查更新时指示。

1. 查询每个服务就绪状态的可能性(如技能服务)是克里斯、我和大卫去年秋天讨论过的问题(应该在待办事项列表中某个地方)我认为这是一个好主意。钩子可以在外部监控此内容时使用，如果发送就绪信号的服务不是第一个加载并准备好发出消息的服务，那么使用轮询查询可能是个好主意。

由于pocketsphinx的回退，可能很难确定它是否完全准备好。处理这个问题的一种方法可能是通知：“我可以使用，但我会在Precise下载时变得更好”。

另一个想法是，我们还在获取设置之前发送mycroft.ready信号，因为上传settingsmeta需要很长时间。这通常是可以接受的，但在配对时没有可用设置的情况下，这可能导致性能下降(Spotify在配对后几分钟才开始播放等)。

Precise也可以预先安装，我一直在研究将其作为我为Focal图像所做的打包工作的一部分打包，并使其成为依赖项，以便一开始就可以随时使用。

感谢Ake,

1. 当没有安装技能时，是否总是这样？
   我没有发现bug。我在运行mycroft-wipe的picroft上观看了这个，它有配对和音量可以加载，但没有其他内容。因此，它报告mycroft.ready一次加载并训练这两个技能，但然后需要下载默认技能的其他部分。

2. 是的，我可以看到这需要仔细考虑正确的中间地带在哪里。我猜想这是缩短启动时间的一部分？我们不想无限期地等待加载，但我也宁愿再等几分钟而不是让用户首次查询完全失败，当这应该是有效的。我之前也没有考虑过技能设置的这种方式......但是这是一个好的观点。

3. 我一直在考虑外部监控，但在短期内，也许一个标准的Service.is_ready(),我们在发出一切正常之前调用它。
   非常同意在镜像上预先安装精确度，这已经包含在当前的Picroft镜像中，它使iso略大一些，但无论如何都需要下载数据。

在擦除之后，根据当前的实现方式，当所有已安装的技能都加载完毕时，无论数量有多少，都是可以预料到的。添加一个check_and_install_defaults()阶段应该是相对容易的，并且对于原始镜像来说，不应该对速度产生太大的影响。
你的假设是正确的，它已经被更改为提高速度，直到操作状态。

要评论@krisgesling在配对技能问题上的陈述；
对我来说，mycroft.ready意味着所有默认技能都已准备好。因此，基本上是特定设备中DEFAULT-SKILLS文件中列出的技能。( https://github.com/MycroftAI/mycroft-skills/blob/20.02/DEFAULT-SKILLS )
优先技能的初始培训仅是为了能够在准备过程中控制设备(重新启动配对过程或控制音量)。
至少这是我对该主题的看法，严重依赖于我mycroft的第一次运行。所以基本上我们完全同意第1点和对此的期望。

我发布了一篇PR,作为如何处理"默认技能丢失"情况的建议。

在经过多次讨论后，我为 mycroft.ready 的建议是，此消息将指示 - 所有五个核心服务[技能、音频、语音、总线、 shell ]都在运行，用户可以完成基本的交互。
更具体地说，这意味着：

• 技能
• 已加载默认技能和任何已安装的技能(除了任何被列入黑名单的)。这意味着最常见的短语可以被处理 - 现在几点了，谁是谁，等等。
• 非默认技能，或需要设置或其他身份验证的技能可能此时尚未准备好。例如，Spotify 技能可能尚未准备好播放音乐，但会报告它需要先同步设置。
• 技能可能尚未更新到最新版本，但预加载的技能应该能够处理请求。
• 音频
• 系统可以输出声音
• TTS 正在运行，对话正在合成(在此之前使用设备缓存)
• 语音
• 用户可以使用设备设置中选择的唤醒词激活设备。这应该是使用 Precise 随发布一起提供的，但可能会回退到 PocketSphinx。
• STT 正在运行，短语被转录
• 总线
• Websocket 服务器已启动，其他服务可以连接。
• 消息正在通过总线发出和检测。
• shell - 取决于每个平台
• 在通用 shell 上 - 只有 shell 代码已初始化并正在总线上监听消息。这是由 is_device_ready() 检查运行所隐含的。

目前的目的是利用来自 PR #2645 的 ProcessStatus 类，使每个服务都能定义和报告自己的就绪状态。短期内， shell 将负责进行整体 is_device_ready() 就绪检查。将来，这可能会移动到一个独立的监控服务中，该服务位于核心之外。
对于上述内容的任何评论、建议或不同意，都非常欢迎。我们真的希望在本月晚些时候的主要 20.08 版本中实现这一点。