openSUSE:osc11 会议改进建议
在 openSUSE Conference 2011 上，举行了一次关于“我们需要改进什么”主题的 BoF 会议。讨论的框架是，我们不会最终得到一个无法实施的冗长“空中楼阁”清单。目标是提出可以在合理的时间范围内（6 个月到 1 年）实施的项目。以下笔记包含讨论的项目
移除 iChain
理由
- 已过时
- 有缺陷
- 专有
- iChain 正在被 Novell Access Manager 替代
- 我们仍然有一个专有解决方案来管理我们的访问权限，尽管 Access Manager 更现代，并且希望更少错误。
潜在问题
- 这可能是一个政治问题，Attachmate 组织内部可能会有人反对
潜在解决方案
使用 OpenID 是替代 iChain 的潜在解决方案。Connect 可以是 OpenID 提供程序，我们可以将事情绑定到 Connect，即，人们需要一个 Connect 帐户，而不是今天需要的 Novell 帐户。Connect 的问题在于，它当前使用 iChain 进行身份验证，并且在使用 iChain 的同时无法充当 OpenID 提供程序。因此，许多人需要设置他们的密码。此外，由于它让人们输入许多信息，可能会给人一种所有这些都是必需的错误印象，从而吓退一些人。
行动
- 在项目会议上讨论如何进行
改进安装程序以处理多引导
多引导安装程序无法正常工作，需要努力改进这种情况。正在进行一些工作，但进展缓慢，因为需要更多帮助。
行动
- 将提交 FATE（BoF 参与者）
- 迫切需要帮助，在 factory 列表中呼吁志愿者。
论坛上有一个脚本可以读取分区并将所需的信息复制到 menu.lst。我现在没有脚本的名称，但会尝试找到它 2011 年 9 月 20 日 01:11 (MDT)
http://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/advanced-how-faq-read-only/458238-updategrub-opensuse-legacy-grub-not-update-grub.html#post2329167 2011 年 10 月 19 日 22:49 (MDT)
Wiki
应翻译更多页面
- 没有真正的进入壁垒
问题
- 没有翻译的优先级
- 翻译者之间没有联系
- 翻译后的页面需要保持最新，这是一项长期承诺
潜在解决方案
- 发布页面浏览量以生成某种排名？
- 每个页面的页脚中发布每个维基页面的页面浏览量
- 向翻译者提供排名？
- 我们可以/大使编译正在翻译的人员列表吗？
- 当翻译者连接时，维护应该更容易，因为它可以由委员会完成
问题
- 我们有很多文档和信息在维基中，但很难访问和找到。
- 页面是否提供其他语言版本的信息是隐藏的
- 无法知道翻译后的页面是否是最新的
潜在解决方案
- 也许以 B 树状结构设置主题
- 也许在每个页面的顶部显示一个栏，显示此页面已被翻译成哪些语言
- 发明一种机制来告知人们翻译后的页面是否是最新的
- 作为 Google Code-in 的一部分，开发了一个解决方案提案，可以在 此处 找到。
改进搜索
问题
- 搜索已损坏，我们需要一个更好的解决方案
- 例如，使用维基搜索搜索 %{?suse_version}，结果是与 SAMBA 相关的链接，而不是与打包相关的链接
潜在解决方案
- 我们可以使用 Google 吗？
- 也许在后台将我们的搜索管道传输到 Google，并仅重新显示以 en.opensuse.org 开头的搜索结果？
- 使用 Google 引擎（可能存在许可问题）
- 确保我们允许“公共”Google 爬虫抓取维基
- 也许在维基上没有搜索，并引导人们到 Google？
- 作为 Google Code-in 的一部分，开发了 此处 找到的提案。
操作
- 在下一次项目会议上讨论一些细节
- Wiki 团队需要参与
openSUSE 需要自己的 bugzilla
理由
- 没有我们控制的 bugzilla 会造成问题
- 分类不是我们想要的
- 我们连接到 iChain 和 Novell 帐户
- 无法进行主题设置
- ...
潜在问题
- 这可能是一个政治问题，Attachmate 组织内部可能会有人反对
- SLE 错误的轻松复制/共享
- 提交错误的门槛是什么？（这与 iChain 的讨论有关）
- 没有进入壁垒，即没有注册，可能会导致大量重复和无效的错误
状态
这个问题在 2010 年 SUSE Labs 会议上提出。Jeff M. 和 Greg KH 完成了初步工作，以运行一个 openSUSE bugzilla。
由于 ACS（Novell 多年前将 IT 管理外包给 ACS）缺乏帮助，因此无法在此问题上取得任何合理的进展。
行动
- 确定当前状态
- 在知道状态后在项目会议上讨论
改进通信基础设施
理由
- 看来很难在社区中传播信息
- 邮件列表太多
- IRC 频道太多
问题
- 我们需要同意哪些频道和列表应该消失或合并
在 2011-10-19 项目会议结束时讨论
- 邮件列表
- 消息限制以获取新的列表不是一种受欢迎的方法
- tumbleweed 似乎可以正常工作，将相关消息发送到 factory（这并不意味着 factory 应该是一个“一揽子”存储桶）。但这并不一定意味着这适用于其他列表“合并”
- 可能需要对“相关主题”进行一些评估，例如
- 也许将 boosters 与 project 列表合并
- 也许 packaging 应该与 buildservice 合并
- 也许 web 和 wiki 应该合并
- 合并低流量列表可能比合并两个高流量列表更容易
- 合并开发特定的列表，例如 ham 和 mobile 可能会很困难，而合并 cloud 和 virtualization 可能是合理的
- 因此，问题仍然是，即使我们找到愿意查看所有列表并提出建议的人，我们将向该人提供哪些指导方针来制定建议？
- 相关主题 - 是的
- 流量指南？
- 订阅者数量？
- 消息限制以获取新的列表不是一种受欢迎的方法
IRC 频道
- 截至 2011-10-19 的 openSUSE/SUSE IRC 频道列表
- 我们有 82 个频道，显然太多了
- 大多数几乎是空的
- 出于明显的原因，必须保留特定于语言的频道
- #opensuse-packaging 应该关闭，因为它几乎是空的，并且 #opensuse-buildservice 具有相同的目的（与同名的邮件列表类似的问题）
建议
- boosters 频道和 project 频道应该合并
- packaging 频道和 buildservice 频道应该合并
理由
- 当前站点无法吸引人
- 信息很难找到
行动
- 让 web 团队参与
- 在项目会议上讨论