Opensuse-docs/prep-meeting-10-23

跳转到:导航搜索

<<< 返回到 Documentation:Meetings

[@ad_himself https://t.me/ad_himself]

2020年10月15日

大家好,抱歉让大家久等了。我们很高兴有你们的参与,并期待完成任务。为了让大家知道“我们”是谁,那就是 @adathor Loquacity @IvoErMejo @DevDorrejo @andres_bs 和我——请原谅我没能提到所有其他人。

下次会议

我们希望下周举行一次视频会议,目标是将自己组织成小组。我们不太确定会议应该在什么时候举行,所以请填写下面的调查问卷。到目前为止,我们一直在会议*之间*的时间里解释、辩论和讨论事情,这样会议*本身*就可以用来记录投票或某种集体共识。我们不能保证我们总能达成一致,但至少这使得我们可以采取具体步骤前进,而不是用每个人的时间来做文书工作。

待办事项

1. 组织结构(见下一节)

2. 检查此列表是否缺少任何内容 (https://docs.google.com/document/d/1zERjqqQrWBAoM3B25BIQ4hvTFU_Y7S8L57bh-wb6ld4/edit?usp=sharing) ,该列表涵盖了更新后的学习体验(无论何种格式)应涵盖的问题。

3. 开始测试不同的内容托管解决方案(参见下一节中的“平台测试人员小组”)。

下次会议前需要思考的问题

我们人数众多,待办事项也很多。所以我认为我们必须同意某些关键角色,这些角色应该在我们之间得到填充,以确保我们都在同一条绳子上拉。我已经与 @adathor 讨论过,我们同意这些角色——请原谅我过于详细的描述,只是为了固定想法(见下一段)。

所以在填写我刚刚发布在 Telegram 群组中的调查问卷之外,如果您能告诉我们

您是否同意这种组织结构,如果您同意但认为角色更多或更少(请分享您的建设性反建议的细节),如果您同意所有内容,您希望填写哪些角色。您现在可以在 Telegram 聊天中执行此操作,或者如果您愿意,可以给我发送消息。如果您有任何不清楚的地方,请告诉我。

角色

  • 连续性守护者(1 人):确保没有人掉队,在会议上做记录,并尝试让邮件列表中的人员了解情况,跟踪谁在做什么等等。
  • 真理探寻者(多人):集体确保长列表中每项内容都是真实的,并且可以安全推荐。在某些情况下(例如,列表中的“?”项),这可能意味着联系一些开发人员或专家,列出优缺点,并解释为什么最终优点胜过缺点。
  • 最紧迫问题收集者(多人):他们扫描所有 openSUSE 相关通信渠道,并对最紧迫的问题进行基本统计(频率 x 痛苦程度),将它们传递给我们,这样我们才不会建立一个与没人需要抽象想法脱节的象牙塔。
  • 视频人员(多人,但不要太多,因为这比较小众,如果太多人一起做饭,可能会一团糟):选择热门主题和问题,提供定制技巧、桌面环境技巧、工作流程技巧等。您在列表中提到的某些内容让我认为视频人员可以真正帮助呈现和直观地解释跨越不同平台(例如,基本上我归类到“回馈社区”下的所有内容)的任务。我不认为这是他们的主要目标,但在对最终用户最有益的方面,我闻到了很大的价值。
  • 平台和界面测试人员(几个人):老实说,除非我们进行测试,否则我们永远找不到托管内容的完美基础设施。问题是,当你列出你希望你的基础设施满足的框框时,你可能会发现你没有选择正确的框框,因为形式和内容以复杂的方式相关联。也许一个简单的做法是从 wiki 开始,然后在我们尝试无法在 wiki 中完成的事情时尽可能地偏离,最后看看所有的偏离是否真的值得。但是的,可能最好的选择介于 wiki 和 https://guide.opensuse.net.cn/ 上提供的非官方指南之间。它至少应该提供
full-text search easy update method
a "view things as a sequence" (as the unofficial guides) view and a "view things as thematically related because you need answers about something in particular" view (as for example here: https://getsol.us/help-center/home/)
a "show more / show less" flip switch to adapt to the knowledge of the user

此外,还有一个想法我们需要考虑平台选择:如果我们愿意,我们可以直接放弃“按顺序查看事物”的呈现方式,并让制作安装程序的人将其变成一个 Web 应用程序——实际上是一个“安装我的 openSUSE 模拟器”。我认为从技术上讲,这并不难,因为安装程序是用某种高级语言(Ruby?)编写的,而该语言本身就非常面向 Web。这意味着我们还需要让他们添加额外的信息框来涵盖我们的所有需求,并拥有“显示更多/显示更少”的切换开关。如果我们走这条路,文档会变得更易于管理:只是

“安装模拟器”;以及全文可搜索的知识库作为我上面链接的 solus 解决方案 (https://getsol.us/help-center/home/)。

干净“交互式”文档呈现的良好示例