Add documentation about type hints

This explains why type hints matter, how they are being added, what are
considered correct type hints and what changes can occur to type hints.

docs/index.rst

@@ -86,6 +86,7 @@ For developers
    CODE_OF_CONDUCT
    docs
    persisting_n3_terms
+   type_hints
 
 Source Code
 -----------

docs/type_hints.rst

@@ -0,0 +1,45 @@
+.. _type_hints: Type Hints
+
+==========
+Type Hints
+==========
+
+This document provides some details about the type hints for RDFLib. More information about type hints can be found `here <https://docs.python.org/3/library/typing.html>`_
+
+Rationale for Type Hints
+========================
+
+Type hints capture the types of variables, function parameters and return types in a way that can be understood by humans, static type checkers like `mypy <http://mypy-lang.org/>`_, code editors like VSCode, documentation generators like Sphinx, and other tools.
+
+Static type checkers can use type hints to detect certain classes of errors by inspection. Code editors and IDEs can use type hints to provide better auto-completion, and documentation generators can use type hints to generate better documentation.
+
+These capabilities make it easier to develop a defect-free RDFLib, and they also make it easier for users of RDFLib who can now use static type checkers to detect type errors in code that uses RDFLib.
+
+Gradual Typing Process
+======================
+
+Type hints are being added to RDFLib through a process called `gradual typing <https://en.wikipedia.org/wiki/Gradual_typing>`_. This process involves adding type hints to some parts of RDFLib while leaving the rest without type hints.
+
+This process is beneficial in that we can realize some of the benefits of type hints without requiring that the whole codebase have type hints.
+
+Intended Type Hints
+===================
+
+The intent is to have type hints in place for all of RDFLib and to have these type hints as accurate and correct as possible.
+
+The correctness and accuracy of type hints are determined by both the standards that RDFLib aims to conform to, like RDF 1.1, and the deliberate choices that are made when implementing RDFLib. For example, given that the RDF 1.1 specification stipulates that the subject of an RDF triple cannot be a literal, all functions that accept an *RDF term* to be used as the subject of a triple should have type hints which excludes values that are literals.
+
+There may be cases where some functionality of RDFLib may work perfectly well with values of types that are excluded by the type hints, but if these additional types violate the relevant standards we will consider the correct type hints to be those that exclude values of these types.
+
+Type Hint Compatibility and Stability
+=====================================
+
+RDFLib more or less adheres to semver 2.0, and for type hints we aim to do the same. This being said, we will not consider corrections to type hints as changes in interface. Corrections to type hints will be considered bug fixes and thus will only necessitate a change in patch version under semver 2.0.
+
+
+
+
+
+
+
+