跳到主要内容

2020-09-22 Conda 社区会议


会议链接

会议在我所在时区的时间

上周会议 无!

出席者

  • 姓名 (首字母)
  • Megan Yancy (MCY)
  • Jonathan Helmus (JJH)
  • Matt B. (MRB)
  • Filipe (FF)
  • Isabela Presedo-Floyd (IRPF)
  • Hameer Abbasi (HA)
  • Marius van Niekerk (MvN)
  • Michael Grant (MG)
  • Michael Sarahan (MCS)
  • Martin Prüsse (MP)
  • Gonzalo Peña-Castellanos (GPC)
  • Peter Wang (PW)
  • Marcel Bargull (MB)
  • Anthony Scopatz (AS)
  • Connor Martin (CJM)
  • Stan Seibert (SRS)
  • Uwe Korn (UK)
  • Amy Williams
  • Angela Gloyna
  • Cheng Lee
  • Christopher 'CJ' Wright (CJW)
  • Crystal Soja
  • Keith Kraus
  • Peter Wang

议程

  • 欢迎

公告

常设事项

  • 讨论:社区需求

新议程项目

  • 讨论:社区需求

前次会议的未完成事项

正在进行的投票

子团队更新

  • 规范子团队

开放的 PR

讨论

时间限制:45 分钟 继续上次关于社区感觉他们没有得到什么的讨论(讨论记录如下,上次会议 20200908/讨论)

  • 社区希望承担哪些责任?*

  • 社区感觉他们缺少什么?

  • 人们在哪些方面感到困惑?是否有其他软件模型可以让我们使用,以便那些想要推动/拥有它的人能够做到?方法的一部分可能是为这些部分创建单独的工作,使其能够不受阻碍地向前发展。(MCS)

    • PR 和审查
      • 更多人审查 PR?
      • 需要更多了解代码的人,但这目前具有挑战性。(庞大、交织的代码库,不太容易理解。)
    • 知识转移(我们如何帮助/培训更多人?)
    • CLA 可能是个障碍
      • 仅仅拥有一个就是障碍(不是实际内容)
      • 有些人确实在原则层面上有异议。
      • CLA 总是需要与 CEO 们进行几轮沟通,然后是律师电话。它们很快获得批准,但在电话发生之前,可能会过去几个月。
    • 在本地机器上运行测试套件也很困难 (AS)
  • 缺乏关于“兼容性”含义的明确标准 (AS) * 识别社区可能更容易解决的问题(唾手可得的成果)的方法 (GPC) * 好的首个问题标签,https://github.com/conda/conda/issues?q=is%3Aopen+is%3Aissue+label%3Agood_first_issue * 与 PR 的沟通,尤其是在多个 PR 解决相同问题时 * 更好地沟通带宽 * 确认收到 PR * PR 审查团队? * 应该问哪个团队? - 更新模板? * Anaconda * 社区 * 更好地沟通期望 * 开放和公开的路线图 * PR 如何融入路线图?

  • 是否有可以从现有大型存储库中提取的具体子项目,可以基于这些子项目进行构建,以促进社区迭代和改进?*

  • 我们能否定义社区可以协作推动的倡议?*

  • 我们能否提名对项目代码库有足够经验的关键社区贡献者,将其晋升为合并权限?*

行动事项

  • 查看问题跟踪器和 PR 跟踪器,以收集一些关于未完成事项的总体视图

  • 建立一个 Conda 社区分类 / Conda 分类团队,以便社区成员和贡献者可以开始提供帮助?

    • 是否设置某种标签来指示肯定应该关闭的问题?
  • 在此 hackmd 上组织关于“短期”/“中期”/“长期”可操作事项的列表?

  • 检查网站上文本的草稿,以便设计过程可以继续进行一些实际内容。

  • 查看当前的 PR,识别我们可以更仔细查看的 PR

    • 为下一次实时审查会议分类问题和 PR
    • 标签权限 - 志愿者,请将姓名添加到列表 - 将在 slack 上提供
    • 包含会议纪要电子邮件链接的电子邮件和 Slack
    • 路线图

以往会议

上次会议 20200908

行动事项

讨论

  • Anaconda 正在寻求转向社区治理模型的里程碑是什么?
  • 哪些可以由社区治理?
  • 将 conda-build 分解为更小的部分?作为单独的项目实施并使其适应 conda?
  • 社区将如何在治理模型中做出贡献?
    • (ED) 在 Anaconda 转向社区治理之前,是否有明确的里程碑?
  • 决策的透明度?
    • (TO) 需要明确什么是社区目标,什么是严格的企业目标,以及什么是两者的混合。
  • Anaconda 一直是 conda 社区的积极支持者,并且一直是许多 conda 工具的出色管理者。现在需要更清楚地了解 conda 生态系统的哪些部分可以由社区治理(社区驱动)。现在有人倡导 conda-build、conda-pack、conda-constructor,甚至 conda 本身都成为社区驱动。
  • Travis 的一些评论关于 Anaconda 员工贡献者在为 conda 社区做贡献时,大多戴着社区的帽子,因此双方可能很难理解何时情况并非如此。这可能会导致这样一种情况,即像 Anaconda 这样非常支持社区的公司,从社区的角度来看,同时可能“难以合作”,除非明确人们在贡献时戴着哪顶帽子。这也是为什么社区治理可能成为一个重要问题,以便人们可以相信项目是根据整个社区而不是仅仅是特定的利益相关者的意愿发展的。
  • 即使 Anaconda 决定暂时让一个或多个 conda 工具保持由 Anaconda 治理,但如果 Anaconda 作为一家企业能够公开透明地沟通项目目标、路线图和优先级,并将它们与 Anaconda 员工作为社区成员的个人愿望和目标分开,那将非常有帮助。Travis 怀疑大多数更改实际上是由 Anaconda 员工作为社区成员驱动的,而不是因为 Anaconda 作为企业指导的工作(但如果能够知道这一点就太好了)。

移至问题跟踪器

当前行动事项