Update docs on strict mode

Update docs on strict mode with more explanation
of when to/not to use it. Include link in
template prompt.

Author: callumforrester

copier.yml

@@ -129,10 +129,10 @@ strict_typing:
     default: false
     help: |
         Would you like to run pyright in strict mode?
-        It is excellent for building consistent, maintainable projects but difficult to adopt on top 
-        of legacy code and projects with many external dependencies. 
         The recommended approach is to start with strict mode and disable it if it 
-        becomes too costly to maintain.
+        becomes too costly to maintain. 
+        See https://diamondlightsource.github.io/python-copier-template/main/how-to/strict-mode.html 
+        for more information.
 
 pypi:
     type: bool

docs/how-to/strict-mode.md

@@ -1,17 +1,13 @@
-# Enable Pyright's Strict Mode
+# Use Pyright's Strict Mode
 
-For projects using pyright you can enable strict mode for stricter than normal type checking. See [the docs](https://github.com/microsoft/pyright/blob/main/docs/configuration.md) for a full breakdown. The primary benefits are increased confidence in code that has been more thoroughly analyzed and a shorter development time thanks to fast feedback from the type checker.
+For projects using pyright you can enable strict mode for stricter than normal type checking. See [the docs](https://github.com/microsoft/pyright/blob/main/docs/configuration.md) for a full breakdown. 
 
-## Configuration
+## How to Enable
 
-Change the `typeCheckingMode` line to `"strict"` in `pyproject.toml` as follows:
+When creating a template, select `pyright` as the type checker and type `y` when prompted to enable strict mode.
 
-```toml
-[tool.pyright]
-typeCheckingMode = "strict"
-reportMissingImports = false # Ignore missing stubs in imported modules
-```
+## Who Should Use Strict Mode?
 
-## Third Party Libraries
+Strict mode enforces good practices such as type hints on function signatures, providing increased confidence in code that has been more thoroughly analyzed and a shorter development time thanks to fast feedback from the type checker. Starting a new project and continually keeping it passing provides a long-term benefit when it comes to maintanability and robustness. However, adopting strict mode on top of legacy projects is likely to lead to lots of errors to work through - probably thousands. Additionally it does not usually work well with libraries that do not have [type stubs](https://github.com/microsoft/pyright/blob/main/docs/type-stubs.md), you will likely need a `# type: ignore` on any line that directly uses the library code. This may limit the usefulness of pyright but it can still be worth doing to ensure your own code is internally consistent.
 
-Strict mode does not usually work well with libraries that do not have [type stubs](https://github.com/microsoft/pyright/blob/main/docs/type-stubs.md), you will likely need a `# type: ignore` on any line that directly uses the library code. This may limit the usefulness of pyright but it can still be worth doing to ensure your own code is internally consistent.
+The recommended approach for brand new projects is to enable strict mode and stick with it for as long as is practical, moving away if it starts to cause more hinrance than help (e.g. because too many major dependencies do not support it).