diff --git a/Python3.md b/Python3.md
index f02a9ae..61cc7a2 100644
--- a/Python3.md
+++ b/Python3.md
@@ -27,8 +27,9 @@ Then:
 4. Now run T's tests on Python 3.
 5. Fix any problems caught by the tests.
 6. Add both M and T to `allmydata/util/_python3.py`.
-7. Submit for code review.
-8. TODO: Not yet possible, but once the ratchet infrastructure is in place, update the should-be-passing-on-Python-3 tests list to include the tests in T plus any other newly passing tests, so that future development doesn't regress Python 3 support.
+7. TODO: Not yet possible, but once the ratchet infrastructure is in place, update the should-be-passing-on-Python-3 tests list to include the tests in T plus any other newly passing tests, so that future development doesn't regress Python 3 support.
+8. Submit for code review.
+9. Check coverage report. If there are uncovered lines, see if you can add tests, or at least file a separate ticket for adding coverage.
 
 ### Porting a specific Python file
 
@@ -44,6 +45,15 @@ if PY2:
     from builtins import filter, map, zip, ascii, chr, hex, input, next, oct, open, pow, round, super, bytes, dict, int, list, object, range, str, max, min  # noqa: F401
 ```
 
+### When things get complicated
+
+In practice, the methodology above is somewhat idealized: a sufficiently important module might have multiple test files, and might not be easily splittable.
+
+This is where the test ratchet comes in.
+The test ratchet ensures that once a specific test is marked as passing in Python 3, it can't stop passing on Python 3.
+As a result, progress in porting need not involve a module being fully ported in one PR, or all tests being made to pass.
+
+Thus, complex modules can be ported over multiple PRs by just increasing the list of passing tests in each PR, and then only marking the module as fully ported in the final PR.
 This adds builtins that match Python 3's semantics. The `#noqa: F401` keeps flake8/pyflakes from complaining about unused imports. We do unused imports so that people changing code later don't have to manually check if `map()` is old style or new style.
 
 **Fourth**, manually review the code. Futureize is nice, but it very definitely doesn't catch everything, or it makes wrong decisions.