docs: add engineering section

[wmontwe]

Resolves #11071

See the follow-up PR for a first example: #11073

[github-actions]

✅ Validation Passed: All report and feature-flag labels are correctly set.

[wmontwe]

I updated the engineering section by describing planning and milestones better. Additionally I clarified GitHub Milestone vs GitHub Milestone Issue.

[dani-zilla]

I'm not against the idea of RFCs on GitHub. Usually when an organization does this though, two problems come up. First is that non-technical users don't know how to interact with GitHub to comment on proposed changes. However, I'm not sure that's as much of a concern here. We still may want to check with our non-engineering stakeholders and contributors, such as product owners and design.

Secondly, is the removal of the comments. Once the RFC goes through the pull request, it's pretty much a static ADR. You have to hunt down the pull request that submitted the file to read through the comments. It's not overly difficult, the file shouldn't have gone through enough changes, especially since future RFCs would get submitted and the ADR would stand as the final version, rather than revising old RFCs. However, preserving the comments, any proposed changes that were left behind, ideas we can come back to, that sort of thing, is a bit more difficult. We could, after submitting the PR, link to it in the doc to resolve that, but it does mean pushing a change to an RFC PR immediately after creating it.

None of these are blockers for this process, just something to think about. If we're inviting non-technical people to make comments and change requests on PRs, we may need some form of documentation on how that process is done (apologies if this already does that, I've not had a chance to review this entire PR yet).

[wmontwe]

Thanks, these are good points to call out.

The engineering docs, RFCs, ADRs, and technical designs are mainly intended for technical contributors and for preserving engineering decisions in a public, discoverable place. Broader product ideas and feature discussions should continue to happen on Mozilla Connect, which is the better entry point for users and non-engineering contributors.

Once an idea from Connect becomes a roadmap item, we usually move into a more structured phase: SoW, RFCs, ADRs, and technical designs. The goal is to move relevant project context into a persisted public form instead of leaving it only in places like Google Drive.

I intentionally left out a design-related process for now, since I think that should be discussed and defined together with design and product rather than being introduced as part of the engineering docs.

On preserving discussion: with our merge flow, the PR number is kept in the merge commit message, so there is still a way back to the original discussion. Linking the RFC PR from the document itself could be useful, but I would treat that as a nice-to-have rather than a blocker.

[dani-zilla]

This is so incredibly useful. Love to see the process laid out with this level of detail and even examples. 👍

[rafaeltonholo]

LGTM!! Thanks for this awesome documentation!

[wmontwe]

@coreycb, @thunderbird/build-release This needs your review as I touched the pull request template.