- be explicit about how to handle naming conflicts
- remove non-goals
- describe when and how to create tails- and tpa-specific profiles

refs tpo/tpa/team#41948

I feel we're missing a big thing here, which is "what do we end up
with at the end here" and "how do we move forward". So here's my
modest proposal of how we could continue the work after the work in
the proposal is completed.

See: team#41948

I have a few concerns with the proposal as it is. I think we're
overlooking a few difficulties, especially naming conflicts, so I'd
like to figure out a plan for that in advance.

I also think it's worth guessing estimates for the work, to get a
better idea of the scale of the work required before we get into
it. This would allow us to create a timeline that would detail a
little more the next steps of the work.

See: team#41948

We don't want to upgrade all modules to latest versions, as that might
be more work than needed. Instead, let's focus on upgrading to
whatever is the latest version between the two codebases.

See: team#41948

Here, we clarify the title to disambiguate with the weirdly similarly
named "Puppet Merge Request Workflow" RFC.

We are also a bit more explicit in somes places, for example:

- we assume we might need to update 3rdparty modules in Tails
- we do *not* assume we switch to a g10k monorepo and instead refer to
- the related issue

See: team#41948

Mostly consistency in capitalization, adding some links to related
issues, spell-checking and splitting long sentences.

See: team#41948

They don't seem to like GitLab links to wiki pages. :-(

See: https://gitlab.torproject.org/tpo/tpa/wiki-replica/-/jobs/820082

Prevent this error:

    (stdin): Kramdown Warning: No link definition for link ID 'toc' found on line 7

See: https://gitlab.torproject.org/tpo/tpa/wiki-replica/-/jobs/820071

refs team#41948

refs team#41948

refs team#41948

refs tpo/tpa/tails/sysadmin#18166

At least one user was confused and put submission.torproject.org, and
used torproject.org as the server name.

I was trying to show how much disk space Prometheus was using and
couldn't find good answers.

donate: rewrite activity diagram to clarify the perk data workflow

See merge request !66

It wasn't clear to me exactly what was going on with those
notes. Ideally, we'd also find a way to automate that synchronization
process (as mentioned above), so it feels better to make an actual
arrow there, even though it doesn't fully reflect the way this
actually works underneath.

I also feel it looks *much* better to move the CiviCRM column to the
left.

See: tpo/web/donate-neo#79

/assign_reviewer @stephen

Closes: tpo/web/donate-neo#79

this was postponed from 2024 and seems relevant

Major documentation updates made to:
- Design and architecture
  - Written description regarding how and why donate-neo design diverged between initial planning and execution
  - Mermaid diagrams outlining both DI-driven data relationships between Django apps and user donation checkout flow
- Technical debt, outlining the friction between donate-neo's PII minimal handling and Stripe Radar's fraud detection algorithm

Minor documentation updates made to:
- Queues, regarding the custom Resque handler and PayPal IPN handling
- Interfaces, regarding PayPal IPN handling
- Implementation, clarifying that CSS and JS are managed via NPM rather than NVM (which itself simply manages local NPM versioning)
- Tests, listing the command for running unit tests

also add a wildcard to the suggested find command so that it matches
things like `hostname.torproject.org.yaml`