Joomla! 开发者网络™

下载
启动

新闻

生产部门团队负责人会议

详情

新的生产部门领导于 2017 年 2 月 9 日举行了一次启动电话会议，讨论部门的现状和活动以及与 Joomla 项目相关的未来计划。由于志愿者门户尚未配置新的 Joomla 项目结构，我们在此共享这些会议记录。

与会人员

  • Michael Babker - 部门协调员
  • Allon Moritz - 媒体管理团队负责人
  • Cliff Pfeifer - 用户体验工作组负责人
  • George Wilson - 框架工作组负责人
  • Niels Braczek - Bug Squad 负责人
  • Philip Walton - CMS 发布团队负责人
  • Puneet Kala - GSoC 团队负责人
  • Roland Dalmulder - CMS 维护团队负责人
  • Sandra Thevenet - 文档工作组负责人
  • Yves Hoppe - 自动化测试工作组负责人

部门协调员的目标

部门协调员分享了他对部门及其团队的高级目标，包括

  • 改善内部和外部沟通（会议记录、博客文章等）
  • 成为团队的推动者
  • 确保所有流程和结构都以可参考的方式记录下来
  • 确保每个团队都有明确定义的目的、职能和角色

对此的进一步讨论引发了一些问题

问：团队应该多久开一次会？
答：建议每 3-4 周一次

问：团队的职能是如何定义的？
答：团队负责人应该了解每个团队目前的职能是什么，并且也应该对他们希望团队完成的目标有一个愿景。因此，团队负责人被委托根据他们已经掌握的信息来定义这些职能。通过协作，可以根据需要完善这些职能。

问：团队如何沟通和发布内容？
答：团队会议报告应根据目前的惯例发布到 志愿者门户。作为生产部门，我们的许多沟通都可能围绕项目的开发展开，因此开发网络应该是我们部门使用的主要子域名。内容在发布之前通常也需要经过营销部门的审查。

Google 代码之夏

该部门快速回顾了 提交的想法，并且 GSoC 团队分享了一个投票电子表格，供所有团队负责人对项目提案进行投票。想法提交于 2 月 10 日截止。团队负责人被要求在 2 月 15 日之前审查并投票表决提案。GSoC 团队还要求帮助 招募导师 参与潜在的项目。

3.x 版本支持结束

在伦敦超级短跑期间，开始了关于 3.x 版本支持结束的讨论，并制定了一个工作计划，即 3.8 将是该系列的最终版本。该部门重申，只要 4.0 版本发布接近 3.8，就支持该计划。鉴于当前 3.8 和 4.0 的计划，部门协调员表示，这两个版本应该同时发布，因此这应该不是问题。根据当前的 项目开发策略，必须在 3.8.0 发布前六个月发布此内容的正式公告。一些关于发布时间表的讨论开始了，部门协调员认为，3.8 和 4.0 可能至少在 3.7 发布六个月后才能达到稳定里程碑。该部门将致力于所需的公告，并根据开发策略发布。

部门资源审查

各团队共同概述了部门当前的资源，包括确定哪些团队未被建立为新的项目团队结构的一部分，确定属于部门责任范围内的项目网站，以及讨论需要关注的领域或需要建立新团队的领域。

有几个人自愿站出来协助维护补丁测试人员；很快就会联系这些人。应该在部门的某个团队（哪个团队待定）下建立一个正式的团队，以确保该项目具有适当的可见性。

接下来讨论了 weblinks 扩展的新发布负责人。其中一位团队负责人自愿承担此责任。还简要讨论了是否应该有一个负责扩展发布的团队，因为目前此活动在某种程度上超出了我们当前的团队讨论范围；对此主题没有答案。

我们简要讨论了“从网络安装”的当前状态及其维护，注意到其团队有些许不活跃，并且最近有一些问题报告没有得到回复。有人指出，该项目也在 JED 的开发聊天中进行了讨论，并且听起来 JED 想要控制该项目。基于此，似乎最好的计划是允许 JED 管理“从网络安装”，并让过去曾为此项目做出贡献的生产部门团队成员随时提供协助。

讨论的最后一个主题是是否需要添加其他团队。两个重点是 CMS 的 JavaScript 资源和项目的编码规范。大家一致认为应该建立一个 JavaScript 团队作为“正式”项目团队，并且应该建立一个编码规范子团队（对此有两个建议，分别在自动化测试团队和文档团队下，目前尚未做出决定）。一旦 OSM 董事会完成官员选举，并且各部门完全过渡到领导项目，协调员将向董事会提议建立一个 JavaScript 工作组。在提交此提案之前，该部门将进一步明确该小组的目的和功能。

项目路线图

该部门的团队发现的一个弱点是缺乏与 CMS 或框架开发相关的连贯路线图。即使在即将发布的 4.0 版本中，也有几个团队和个人正在处理多个项目或对发布应该包含的内容或如何进行转换有不同的看法。此外，4.0 分支现在有超过 1200 次提交，其中包含多个功能更改，但没有任何关于这些更改的明确文档。总的来说，这个讨论领域被分解成几个不同的部分进行讨论。

最低支持软件堆栈

讨论了 4.0 分支当前支持的最低限度。在此期间，主要关注的领域是是否应该针对更高的 PHP 最低版本。根据当前的使用统计数据、各种操作系统或其软件包库的分发情况以及当前的 PHP 生态系统，5.5.9 仍然是一个合理的目标。但是，各团队将继续监控与之相关的所有因素（以及其他软件堆栈），并将继续重新评估此决定，直至 4.0 版本发布时，届时将锁定该版本系列的最低版本。

文档

目前，发布的唯一文档位于 GitHub 和各种拉取请求中。与过去的版本类似，需要建立一个文档页面，说明各种向后兼容性中断并记录扩展的迁移路径。

注意 会议结束后，启动了一个 文档页面 以收集这些信息，并将链接分享给团队负责人。

文档的第二个关注领域与帮助屏幕系统相关。文档负责人注意到当前的解决方案变得难以管理；内容量巨大，难以管理和翻译，并且缺少一些功能（迄今为止，没有针对新 3.7 功能的屏幕）。对可能的替代方案进行了一些讨论，包括其中一个 GSoC 提案的可能性，并且稍后将对该主题进行进一步讨论。由于潜在的 GSoC 项目，考虑到该项目的计划时间表，该主题将成为讨论的优先事项。

编码规范提案

关于 Joomla 是否应该采用 PSR-12 作为现有 PHP 编码规范的替代方案，并在 PHP-FIG 接受后进行调整，已在 GitHub 上发起了一个 RFC 进行讨论。这是一个更新的编码规范提案，用于替换 PSR-2。采用该提案的关注点包括：这可能会使所有打开的拉取请求失效（需要更新代码样式更改）以及如何在不同项目仓库的版本分支之间合并代码变得复杂。鉴于 CMS 存储库中的代码行数以及如果仅对 4.0 分支采用代码样式，后者会变得更加复杂。该部门很快将对此进行投票。

预算

该部门审查了 PLT 投票通过的 2017 年预算，并同意该提案。

代码冲刺优先级

会议结束时简要讨论了今年的代码冲刺优先级，大家一致认为 4.0 的开发应为最高优先级。协调员要求各团队为他们希望在今年开展的冲刺活动撰写简短的提案，以便能够妥善规划。