Merge branch 'main' into relbot/upgrade-geckoview-ac-main

android-components/components/browser/state/src/main/java/mozilla/components/browser/state/engine/middleware/TranslationsMiddleware.kt

@@ -198,7 +198,7 @@ class TranslationsMiddleware(
                             isEngineSupported = isEngineSupported,
                         ),
                     )
-                    logger.info("Success requesting engine support.")
+                    logger.info("Success requesting engine support. isEngineSupported: $isEngineSupported")
                     continuation.resume(isEngineSupported)
                 },
 

docs/rfcs/0000-template.md

@@ -0,0 +1,46 @@
+---
+layout: page
+title: your title
+permalink: /docs/rfcs/file-name
+---
+
+* RFC PR: [PR #](https://github.com/mozilla-mobile/android-components/pull/#)
+* Start date: YYYY-MM-DD (Day of proposal posting.)
+* End date: YYYY-MM-DD (Last day for general feedback. However, the proposal can be merged immediately after all stakeholders approve.)
+* Stakeholders: github-username, github-username
+
+## Summary
+
+This section should include a brief description of the proposal.
+
+## Motivation
+
+This section should include reasoning about why the proposal is useful. Examples, specific scenarios, 
+open bugs, records of performance metrics, and other empirical data are beneficial to include here if available.
+
+## Guide-level explanation
+
+This section should include a high-level walkthrough of the steps required to implement the proposal.
+
+## Reference-level explanation (optional)
+
+This section should include a detailed walkthrough of technical steps or code changes that 
+will be required to implement the proposal. Code samples and prototypes are beneficial to include here.
+
+## Drawbacks (optional)
+
+This section should include any drawbacks to the proposal.
+
+## Rationale and alternatives
+
+This section should include any alternative proposals considered, as well as the rationale for why
+they were not selected for the proposal.
+
+## Resources and Docs (optional)
+
+- Any (internal or external) similar proposals  or other documentation that shares concepts with the proposal.
+- Links to artifacts generated as part of the proposal, such as additional documentation or follow-up bugs.
+
+## Unresolved questions
+
+Questions from the proposal author or from reviewers that are not yet resolved.

docs/rfcs/0013-rfc-process-updates.md

@@ -0,0 +1,48 @@
+---
+layout: page
+title: RFC process updates
+permalink: /docs/rfcs/0013-rfc-process-updates
+---
+
+* RFC PR: https://github.com/mozilla-mobile/firefox-android/pull/5681
+* Start date: 2024-02-20 
+* End date: 2024-03-22 
+* Stakeholders: @jonalmeida, @boek
+
+## Summary
+
+Clarify requirements for RFCs by introducing a README and a template.
+
+## Motivation
+
+- The scale of the Firefox Android team has grown substantially since the RFC process was first introduced. 
+- More external teams are using and contributing to Android Components. 
+- Implicit deadlines have encouraged a lack of engagement with RFCs, slowing follow-up work.
+- There has been a low level of engagement with RFCs because of a lack of clarity around the process and when they are appropriate.
+
+## Guide-level explanation
+
+This proposal suggests improving the RFC process by introducing the following:
+
+- An RFC template, to provide a clear starting point for proposals.
+- A guide for when RFCs are appropriate and when they are not needed in the form of a README.
+- A requirement for explicit stakeholders for RFCs.
+- An initial deadline recorded in each proposal.
+- A renaming of the the "Prior Art" section to "Resources and Docs" and wording to indicate that proposals can also include additional documentation.
+
+## Rationale and alternatives
+
+The RFC process has been successful in some cases, but has not been consistently followed. This proposal aims to make the process more accessible and clear, by introducing high-level concepts in the README and a clear template. These documents can be more easily treated as living documents, and updated with any future changes to the process.
+
+### Amend RFC 0001 with additional template information
+- This was not included in the proposal in order to keep past RFCs consistent and free of modern context, and so that past RFCs do not become treated as living documents. 
+
+## Resources and Docs
+
+[README](./README.md), a new artifact that includes guidelines and advice on when RFCs are appropriate and how to contribute them.
+[0000 RFC Template](./0000-template.md), a new artifact that provides a clear starting point for proposals.
+[Follow-up bug for updating CODEOWNERS](https://bugzilla.mozilla.org/show_bug.cgi?id=1881373), so that stakeholders can be found more easily.
+
+## Unresolved questions
+- Will this result in an easier process for contributors to follow?
+- Will this result in more engagement with RFCs?

docs/rfcs/README.md

@@ -0,0 +1,47 @@
+# The RFC Process
+
+An RFC (**R**equest **F**or **C**omments) is a process through which contributors can solicit buy-in
+for proposed changes to the codebase and repository at-large. It was introduced in the first RFC,
+[0001-rfc-process](./0001-rfc-process.md), which includes additional details about the reasoning
+for including the process. 
+
+This is an overview of what kind of changes benefit from or require the consensus-building that the 
+RFC process provides, as well as a brief guide on how to draft them.
+
+## What kinds of changes require an RFC?
+
+1. Substantial changes to public APIs in Android Components, like the changes found in [0003 Concept Base Component](./0003-concept-base-component.md) and [0008 Tab Groups](docs/rfcs/0008-tab-groups.md). 
+2. Changes to process that affect other teams, like the changes found in [0001 RFC Process](./0001-rfc-process.md), [0013 Add stakeholders to RFCs](./0013-rfc-process-updates.md), and [0007 Synchronized Releases](./0007-synchronized-releases.md).
+3. Proposals for changes to areas of the codebase that are owned by CODEOWNERS outside the author's team.
+
+## What kind of other changes can an RFC be useful for?
+
+1. Announcing a rough plan for changes to a public API you own in order to solicit feedback.
+2. Soliciting feedback for architectural changes that affect the entire codebase, like [0009 Remove Interactors and Controllers](./0009-remove-interactors-and-controllers.md).
+
+## How to contribute an RFC
+
+There is a [template](./0000-template.md) that can be a useful guide for structure.
+
+While drafting a proposal, consider the scope of your changes. Generally, the level of detail should match the level of 
+impact the changes will have on downstream consumers of APIs, other teams, or users.
+
+Once a proposal is drafted:
+
+1. Choose a deadline for general feedback.
+2. Select and communicate with stakeholders.
+3. Share the RFC more broadly through Slack and mailing lists for general feedback (like firefox-android-team@ and firefox-mobile@).
+4. Build consensus and integrate feedback.
+
+### Stakeholders
+
+Stakeholders are required for each RFC. They will have the final say in acceptance and rejection. 
+Include at least 2 people as stakeholders: a CODEOWNER of the affected area and another (preferably a Firefox for Android team member).
+
+Stakeholders should be active in the RFC process - they should ask to be replaced if they do not have bandwidth to get the RFC finished in a short time span. This is to help the RFC process remain nimble and lightweight.
+
+### Deadlines
+
+A deadline for feedback should be included in each RFC. This should usually be at least a week, so plan accordingly. 
+For more substantial changes, it can be useful to plan for 2 or 3 weeks so that there is more opportunity for feedback from people that are not stakeholders.
+If a proposal is approved by all stakeholders earlier than the deadline, the proposal can be merged immediately.