This is a great start.

When adding new changes, its good to run the full test suite and not just the relevant tests, so that you know whether your changes lead to any unexpected breakages.
If a test passes on the main branch, but fails on your branch, then you know that your change broke something. If it fails on both branches, then this is something that was already broken and you don't need to worry about it for this change (but you should still mention it to us.)

This looks like it can all fit on one line and still be less than 79 chars.

Lets be more specific here and say "review requests" instead of "new posts".

from djblets.siteconfig.models import SiteConfiguration should be placed on the line before from djblets.testing.decorators import add_fixtures.
Imports in the same group should be sorted alphabetically (so S before T).

These need to be moved to the same import group as the other django import on line 5. Files have 3 import groups:

- Python Standard Library imports

- Third-party module imports (django, kgb, six, pkg_resources, etc.).

- Project imports.

See more detail here

This needs a docstring. It can be as simple as
"""Setup for a unit test."""

This needs an Args: section in the docs and a Returns: section, as well as typing.

Missing a -> None:

Leftover code that should've been deleted?

This is a nit, but we like to sort the keys alphabetically. You could do that here and for the other dictionaries below.

Add a blank line before the comment.

Hey Daniel,
It looks like you've pulled on your master branch, but your branch is still coming off of a previous revision. The diff you've posted here therefore has a bunch of unrelated stuff.
You're going to want to rebase your branch onto the latest master. See https://www.notion.so/reviewboard/Keeping-Commit-Histories-Clean-0f717c4e802c4a0ebd852cf9337ce5d2?pvs=25#ef7f7a64bfd64d49b44eea1e066e5e1e for details on that. After rebasing, please post this change again.

In the description on your review request (which will get turned into the commit message that's stored for all time), we don't want to describe the mechanics of the change (added X method to Y file), because that's what the diff is for.
Instead, we should explain at a high level what the change accomplishes and why we're doing it. In this case, you'd want it to say that we're adding a new setting to the user profile to let them save a default value for the "Archive after publishing" feature, plumbing that setting through to the frontend JS, and adding a new checkbox in the user preferences form to let them change it.

Similarly, in the testing done field, we don't need to say exactly what files were changed. You can just say that you added new unit tests to cover certain cases. You probably should also run the entire python test suite as well as just your newly-added tests.

While you're here, would you mind sorting the keys in alphabetical order?

Looks like a leftover from when you had this as a DB field.

The first line of the docstring needs to fit on one line here. You can add an additional paragraph after if you need to be more wordy.

Same here.

The variable definitions and setUp() method should be at the top of the class, not under any test methods.

Please add doc comments for these.

This method should call super.setUp() as its first line.

This looks unused, and even if you did need to do something with siteconfig, you shouldn't need to create your own instance. Can we just remove this?

For legacy reasons, our test case docstrings should be of the format "Testing ..." and not end in a period. Here and below.

Do we need the or False here?

When there are more arguments than just self, each argument should be on their own line like this:
publish_and_archive(
    self,
    archive: bool,
) -> None:

django and djblets imports should be in the same group (third party imports) so this blank line should be removed.

The 2nd and 3rd """ here should be deleted.

Instead of putting the instance variable docs in the class docstring, they should instead be written out above each variable using #: comments. See the UIThemeRegistryTests class in reviewboard/themes/tests/test_ui_theme_registry.py for an example of what this looks like. You'll also need to add an "Instance Variables" comment header, which you'll see in that class as well.

On Python3+ we don't need to include the class name and self when calling super, you can instead do super().setUp(). We also like to put a blank line after calling super()

Add a blank line before this comment.

You can also change any "Version Added"s that you have from 7.0 to TODO, like you did in your frontend change.

If we're going to be reformatting all of these lines, we should add type hints while we do it. If we don't want to touch these, we should revert these formatting changes.

There should be a blank line after a class docstring.

For documenting instance members, we format it like this:

class X:
    """..."""

    ######################
    # Instance variables #
    ######################

    #: The HTTP request.
    request: HttpRequest

    #: The user profile.
    profile: Profile

    #: The user to test with.
    user: User

I know if might be a fair bit of work, but it would be really nice to pull the type annotation changes in reviewboard/accounts/models.py out into their own review request. It's best to keep each change focused on one task.

Let's clarify that this is the user's preferred default value for the "Archive after publishing" setting, and not that it will always happen.

The Model import should be inside an if TYPE_CHECKING: block at the bottom of the import list (you can import TYPE_CHECKING in the from typing ... line)

AvatarService should also be inside if TYPE_CHECKING

TrophyType should also be inside if TYPE_CHECKING

I think we can type local_site as Optional[AnyOrAllLocalSites] (importing that from reviewboard.site.models). I don't know why int was included in the documentation -- perhaps Christian can shed some light on that.
Same for others in this file.

This can go away.

Copy/paste-o: ThemeForm -> AccountSettingsForm

When concatenating strings like this, our convention is to put the space at the end of the previous line instead of the beginning of the next.

Because this is a @property, we can document it as if it was a value instead of a function. ("Whether to ..." instead of "Return whether to ...")