社区提案：优化沟通与任务管理流程
#577
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
-
背景
目前，HAMi 项目的主要沟通方式仍然集中在微信群，讨论内容在私域中沉积，造成以下问题：
沟通内容以聊天记录的形式沉积，难以系统化跟踪
信息分散，重复沟通增加了时间成本，FAQ 反复回答
后来的社区伙伴难以在微信群中看到完整的讨论和决策过程，降低了参与积极性
为了解决这些问题，我们计划逐步将沟通转移到 GitHub Discussions 中，以提高信息的透明度和可追溯性，优化任务管理，进而提升团队和社区的协作效率
目标
减少微信群中沉积的信息，将主要讨论转移至 GitHub Discussions
建立系统化的沟通与任务管理流程，提升信息共享和项目透明度
提高社区参与积极性，为外部贡献者提供更清晰的任务进度和讨论内容
提案内容
主要沟通平台迁移至 GitHub Discussions
仍然使用 GitHub Issues 作为核心任务管理工具，而非引入 Projects
module/scheduler、module/webhook、module/device-plugin，但是如果运营侧没人专门做这个，光靠开源用户自觉，就还是很难坚持下去社区活跃度提升措施
实施计划
逐步迁移沟通至 Discussions：引导群里成员优先在 Discussions 中发起讨论，确保信息沉淀，ISSUE-TEMPLATE 也可以参考这个进行修改
定期总结进展：每周总结 Issue 和 Discussions 的进展，并在微信群中进行简单通报，一定要简短
参考指标
Issue 解决率：Issue 在 Milestones 维度的按期完成率逐渐提升
社区参与度：每周在 Discussions 参与讨论的社区成员数量逐步增加
微信群讨论度：微信群中的讨论量减少，逐步将内容转移到 GitHub 上
总结
无需引入 Projects 看板，通过简化的 GitHub Issues 和 Discussions 流程，本提案旨在以尽量小的管理负担提升沟通和任务的透明度，使咱们团队逐步适应异步协作，提高社区成员的参与度，为项目后续发展打下基础
其他
关于切换主要沟通方式的担忧：
关于不建议现在引入 Projects 管理流程：
和上面担忧的出发点一样，现阶段的组织规模和活跃度还没到要引入类似于下面这种管理流程的程度，从 Discussions 里面提炼或收集需求，形成 Issue，然后管理好 Issue 肯定是够了的
sequenceDiagram participant Discussions participant ISSUE participant Projects【ToDo】 participant Projects【InProgress】 participant Projects【Review】 participant Projects【Done】 Discussions->>ISSUE: 讨论后按需创建 ISSUE->>Projects【ToDo】: 自动归类为 Projects【ToDo】 Projects【ToDo】->>Projects【ToDo】: 分类+Tag Projects【ToDo】->>Projects【InProgress】: 分发/认领 Projects【InProgress】->>Projects【Review】: 提 PR Projects【Review】->>Projects【Done】: 审查通过 Projects【Done】-->>Projects【ToDo】: 每周更新关于讨论语言：
Beta Was this translation helpful? Give feedback.
All reactions