ADR0001: clarify when/where Python 3.6+ is expected

Provide additional context to clarify where we expect Python 3.6+ to be used
exclusively (new modules) and link to other discussions around the future of
Python 2.7 supporting code.

Signed-off-by: Joshua Lock <[email protected]>

docs/adr/0001-python-version-3-6-plus.md

@@ -7,9 +7,11 @@ Technical Story: https://github.com/theupdateframework/tuf/issues/1125
 
 ## Context and Problem Statement
 
-We do not want to try and support end-of-life versions of the language.
-We want to use modern language features, such as typing.
-We want to ease maintainer burden, by reducing the major language versions supported.
+We are planning a refactor of tuf where:
+
+* We do not want to try and support end-of-life versions of the language.
+* We want to use modern language features, such as typing.
+* We want to ease maintainer burden, by reducing the major language versions supported.
 
 ## Decision Drivers
 
@@ -30,10 +32,17 @@ We want to ease maintainer burden, by reducing the major language versions suppo
 Chosen option: "Support only Python 3.6+", because we want modern features and lower
 maintainer effort as we work to improve our codebase through the refactor effort.
 
+New modules should target Python 3.6+.
+
 Using modules to polyfill standard library features from Python 3.6+ feels
 untenable as more libraries are dropping support for EOL Python releases.
 
 ### Negative Consequences
 
 * Leaves major adopter and contributor without an actively developed client for some of
   their customers stuck on older Python versions.
+
+## Links
+
+* [Discussion of how/where to develop the refactored codebase](https://github.com/theupdateframework/tuf/issues/1126)
+* [Discussion of deprecation policy for the pre-1.0, Python 2.7 supporting, code](https://github.com/theupdateframework/tuf/issues/1127)