Firefox for Android 团队流程¶
沟通渠道¶
对于 Firefox Android 内部沟通，请先在 #mobile-android-team 中开始。
Matrix 上的专用频道也可以使用
#Fenix - Fenix 开发讨论。
#android-components - 我们移动浏览器/项目的共享核心组件。
#geckoview - 处理 Gecko 的 Android 层，该层与 Android 组件和 Fenix 交互。
设计可行性¶
谁：设计主管、设计师、工程主管、工程师、产品主管、产品经理 目的：在开始设计新功能（尤其是大型功能）时随时召开会议进行讨论
整体概念和用户目标
功能在 Fenix 系统中的位置
任何现有的技术限制或依赖关系（Android 操作系统或其他 Firefox 移动团队，如 GV 或 A-C）
用户故事的一致性
设计移交 谁：设计师、工程师、产品经理、QA 主管 目的：在功能的工程冲刺开始之前进行讨论
功能的总体目的及其与现有功能的关系或交互方式
讨论功能的预期
讨论视觉和交互设计元素
协商范围并在任务太大而无法在一个冲刺中完成时讨论更改
问题分类¶
团队异步分类 Bugzilla 问题。这包括审查所有新问题（错误、崩溃和功能请求），以确定是否应在 MVP 中解决或添加到积压工作中以供将来冲刺使用。
流程¶
冲刺计划¶
冲刺预计划：¶
根据准备就绪情况（UX/依赖项）、优先级和复杂性构建冲刺计划。
冲刺计划期间：¶
将故事/错误分配到冲刺，直到达到容量，并解决任何未决问题。
根据需要调整故事大小。大多数大小调整是异步进行的。
回顾 UX 冲刺计划
积压工作整理¶
在积压工作整理期间，审查并所有分配给积压工作但尚未调整大小的用户故事。
…
冲刺期间¶
工程师将在他们开始处理故事时将其标记为“进行中”，并将故事分配给自己。
如果用户故事具有需要审查的 UX 组件，则在准备好进行审查时，工程师将添加屏幕截图/gif 并 @提及用户故事中的设计师。在 PR 中添加 needs:ux-review 标签。
在 PR 合并后，合并者将验证此代码将发布到问题的里程碑中。（注意软代码冻结！发布可能已经完成，这会影响当前的里程碑。）
当工单准备进行测试时，工程师将使用 eng:qa:needed 标签标记故事。
QA 将使用 eng:qa:verified 标签标记故事并关闭工单（这会将其移动到“已完成”列）。
如果工单被阻塞并且会错过冲刺，工程师将将其标记为“等待中”并通知产品团队原因。此问题将移回相应的积压工作中。
工程师将删除“等待中”标签并重新应用相应的标签（“进行中”、“需要 QA”）。
UX 审查¶
如果用户故事具有需要审查的 UX 组件，则在准备好进行审查时
考虑与设计师进行“桌面检查”电话会议*
工程师将添加 gif/屏幕截图/apk（适用于问题）
工程师将在用户故事中@提及设计师并在 Slack 上 ping 设计师，并添加
needs:UX-feedback标签UX 设计师审查组件（考虑进行电话会议以解决次要更改）。设计师和工程师在如何处理编辑方面之间的沟通至关重要。
我们还将在冲刺演示期间进行 UX 审查。
文案审查¶
如果用户故事具有需要审查的字符串，则在准备好进行审查时
在 Fenix 中作为功能请求提出问题。
添加 needs:strings 标签。
添加将应用字符串的屏幕截图。
添加用例的详细说明。
评论请求 UX 设计师审查。
工程审查¶
在打开的 PR 上使用标签来显示它处于流程的哪个部分。一些值得注意的标签
needs:review - 需要审查的 PR。任何人都应该使用此标签跳到任何审查并帮助进行审查。提前感谢。
pr:needs-ac - 正在等待 AC 提升的 PR。通常，我们使用“等待中”，但这为我们提供了更多上下文。
pr:approved - 已批准的 PR。与 GitHub 摘要中的“已批准”相比，此标签更易于视觉解析
pr:waiting-for-authors - 已获批准并正在等待任何更改才能着陆的 PR。通常，PR 可能已获批准，但尚未着陆，因为它正在等待后续更改。
QA¶
当工单准备进行测试时，工程师将使用 eng:qa:needed 标签标记故事（这会将工单移动到“准备进行 QA”列）。
QA 将审查工单并确定它是否可以手动测试。如果不需要 QA，QA 将关闭工单并将其移动到“已完成”列。
如果发现缺陷
将在故事中添加评论@提及工程师
缺陷链接为故事的依赖项
已删除“需要 QA”标签。
相关故事设置为“进行中”。
修复缺陷后，工程师将再次为故事添加“需要 QA”标签。
修复所有严重缺陷后，QA 将使用“QA 已验证”标签标记故事并关闭工单（这会将其移动到“已完成”列）。
测试代码更改的性能影响¶
性能团队为此编写了参考文档：https://wiki.mozilla.org/Performance/Fenix/Performance_reviews
无障碍¶
在设计审查期间，我们应该问问自己是否需要自定义 UI 来实现所需的交互。通常，开箱即用的 android UI 具有内置的无障碍和本地化功能，而对于自定义部分，我们需要自己构建。
对于具有 Fenix 独有或用户交互的 UI 元素的新功能，请使用 TalkBack 亲身测试（就像您在提交补丁之前测试功能是否正常工作一样）
在提交补丁之前，在受影响的屏幕上运行无障碍扫描程序以确保没有引入新问题（并发布结果的屏幕截图）
QA 应使用启用辅助功能服务（如 TalkBack）测试具有“eng:qa:needed”标签的工单，并且只有在这些服务与新功能配合良好时才将其标记为“eng:qa:verified”
如工单中所述，QA 团队将随着时间的推移将辅助功能检查添加到 UI 测试中
请记住：我们在流程中越早发现问题（越接近开发编码或 UX 设计），对所有相关人员的工作量就越少！因此，请在提交补丁之前认真执行这些检查。
模板¶
我们为新问题创建了模板，其中包含有关如何根据其请求/性质填写这些模板的说明 此处
更多详细信息请参见 流程文档和流程图链接
添加语言环境¶
可以在 Pontoon 上查看不同语言环境的完成率。在项目处于预览阶段时，Firefox 预览版和 Firefox 预览版 Nightly 之间的语言环境将相同。在我们进行下一次大型里程碑发布之前，我们将更新发布语言环境以匹配 L10N 批准的已达到足够本地化完成率的语言环境。