1 files changed, 47 insertions, 0 deletions
diff --git a/lang/python/docs/README b/lang/python/docs/README
new file mode 100644
index 00000000..a14e1ad5
--- /dev/null
+++ b/lang/python/docs/README
@@ -0,0 +1,47 @@
+GPGME Python Bindings Documentation
+===================================
+
+As the GPGME Python bindings exist in two worlds within the FOSS
+universe, it's always had a little issue with regards to its
+documentation and specifically to the format of it.  The GnuPG
+Project, like much of the rest of the GNU Project, uses Texinfo to
+build its documentation.  While the actual format used to write and
+edit that documentation is Org mode.  Largely because most, if not
+all, of the GnuPG developers use GNU Emacs for much of their work.
+
+The Python world, however, utilises reStructuredText almost
+universally.  This in turn is used by Sphinx or Docutils directly to
+build the documentation.
+
+Each has various advantages for their own ecisystems, but this part of
+the GnuPG effort is aimed at both sides.  So, long story short, this
+documentation is provided as both Texinfo and reStructuredText files.
+
+This docs directory contains four main subdirectories:
+
+ 1. meta
+ 2. src
+ 3. rst
+ 4. texinfo
+
+The Meta directory is for docs that are not intended for distribution
+or are about the docs themselves.  The sole exception being this RDME
+file.
+
+The Src directory is where the original edited files are, from which
+the following two formats are generated initially.  Most, if not all,
+of these are written in Org Mode.
+
+The ReST directory contains reStructuredText files ehich have been
+converted to that format from the Org Mode files via Pandoc.
+
+The Texinfo directory contains Texinfo files which have been exported
+to that format from the Org Mode files by Org Mode itself within GNU
+Emacs.
+
+Those latter two directories should then be used by their respective
+build systems to produce the various output file formats they normally
+do.  They should not spill out into this parent directory.
+Particularly since it is quite possible, perhaps even likely, that
+alternatives to both of them may be added to this parent documentation
+directory at some future point.