ENH: User and developer guide as RestructedText **WIP**

[ci  skip]

Author: jcfr

.gitignore

@@ -19,3 +19,6 @@ tags
 
 # Ignore pyc files ...
 *.pyc
+
+# Documentation
+Docs/_build

AUTHORS.rst

@@ -0,0 +1,5 @@
+=======
+Credits
+=======
+
+Please see the GitHub project page at https://github.com/Slicer/Slicer/graphs/contributors

CONTRIBUTING.md renamed to CONTRIBUTING.rst

@@ -1,109 +1,117 @@
+======================
 Contributing to Slicer
 ======================
 
 There are many ways to contribute to Slicer, with varying levels of effort.  Do try to
-look through the [documentation](https://www.slicer.org/wiki/Documentation/Nightly/Developers) first if something is unclear, and let us know how we can
+look through the `documentation <https://www.slicer.org/wiki/Documentation/Nightly/Developers>`_ first if something is unclear, and let us know how we can
 do better.
 
-  * Ask a question on the [slicer-devel email list](http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel)
-  * Submit a feature request or bug, or add to the discussion on the [Slicer issue tracker](http://na-mic.org/Mantis)
-  * Submit a [Pull Request](https://github.com/Slicer/Slicer/pulls) to improve Slicer or its documentation
+  * Ask a question on the `slicer-devel email list <http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel>`_
+  * Submit a feature request or bug, or add to the discussion on the `Slicer issue tracker <http://na-mic.org/Mantis>`_
+  * Submit a `Pull Request <https://github.com/Slicer/Slicer/pulls>`_ to improve Slicer or its documentation
 
 We encourage a range of Pull Requests, from patches that include passing tests and
 documentation, all the way down to half-baked ideas that launch discussions.
 
 The PR Process, Circle CI, and Related Gotchas
 ----------------------------------------------
 
-#### How to submit a PR ?
+How to submit a PR ?
+~~~~~~~~~~~~~~~~~~~~
 
 If you are new to Slicer development and you don't have push access to the Slicer
 repository, here are the steps:
 
-1. [Fork and clone](https://help.github.com/articles/fork-a-repo/) the repository.
+1. `Fork and clone <https://help.github.com/articles/fork-a-repo/>`_ the repository.
 3. Create a branch.
-4. [Push](https://help.github.com/articles/pushing-to-a-remote/) the branch to your GitHub fork.
-5. Create a [Pull Request](https://github.com/Slicer/Slicer/pulls).
+4. `Push <https://help.github.com/articles/pushing-to-a-remote/>`_ the branch to your GitHub fork.
+5. Create a `Pull Request <https://github.com/Slicer/Slicer/pulls>`_.
 
-This corresponds to the `Fork & Pull Model` mentioned in the [GitHub flow](https://guides.github.com/introduction/flow/index.html)
+This corresponds to the ``Fork & Pull Model`` mentioned in the `GitHub flow <https://guides.github.com/introduction/flow/index.html>`_
 guides.
 
 When submitting a PR, the developers following the project will be notified. That
-said, to engage specific developers, you can add `Cc: @<username>` comment to notify
+said, to engage specific developers, you can add ``Cc: @<username>`` comment to notify
 them of your awesome contributions.
 Based on the comments posted by the reviewers, you may have to revisit your patches.
 
 
-#### How to efficiently contribute ?
+How to efficiently contribute ?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We encourage all developers to:
 
 * review and follow the style guidelines described
-[on the wiki](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Style_Guide#Commits).
+  `on the wiki <https://www.slicer.org/wiki/Documentation/Nightly/Developers/Style_Guide#Commits>`_.
 
 * add or update tests. There are plenty of existing tests to inspire from. The
-  testing [how-tos](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/Testing) are
+  testing `how-tos <https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/Testing>`_ are
   also resourceful.
 
 * consider potential backward compatibility breakage and discuss these on the
   mailing list. For example, update of ITK, Python, Qt or VTK version, change to
   core functionality, should be carefully reviewed and integrated. Ideally, several
   developers would test that the changes don't break extensions.
 
-#### How to integrate a PR ?
+How to integrate a PR ?
+~~~~~~~~~~~~~~~~~~~~~~~
 
 Getting your contributions integrated is relatively straightforward, here
 is the checklist:
 
 * All tests pass
 * Consensus is reached. This usually means that at least two reviewers approved
-  the changes (or added a `LGTM` comment) and at least one business day passed
-  without anyone objecting. `LGTM` is an acronym for _Looks Good to Me_.
+  the changes (or added a ``LGTM`` comment) and at least one business day passed
+  without anyone objecting. `LGTM` is an acronym for `Looks Good to Me`.
 * To accommodate developers explicitly asking for more time to test the
   proposed changes, integration time can be delayed by few more days.
 
 Next, there are two scenarios:
+
 * You do NOT have push access: A Slicer core developer will integrate your PR. If
   you would like to speed up the integration, do not hesitate to send a note on
   the mailing list.
-* You have push access: Follow [Integrating topic from external contributor](https://www.slicer.org/wiki/Slicer:git-svn#Integrating_topic_from_external_contributor)
+* You have push access: Follow `Integrating topic from external contributor <https://www.slicer.org/wiki/Slicer:git-svn#Integrating_topic_from_external_contributor>`_
   instructions on the wiki.
 
 
-#### Automatic testing of pull requests
+Automatic testing of pull requests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Every pull request is tested automatically using CircleCI each time you push a
 commit to it. The Github UI will restrict users from merging pull requests until
 the CI build has returned with a successful result indicating that all tests have
 passed.
 
 The testing infrastructure is described in details in the
-[3D Slicer Improves Testing for Pull Requests Using Docker and CircleCI](https://blog.kitware.com/3d-slicer-improves-testing-for-pull-requests-using-docker-and-circleci/)
+`3D Slicer Improves Testing for Pull Requests Using Docker and CircleCI <https://blog.kitware.com/3d-slicer-improves-testing-for-pull-requests-using-docker-and-circleci/>`_
 blog post.
 
 
-#### Nightly tests
+Nightly tests
+~~~~~~~~~~~~~
 
 After changes are integrated, every evening at 10pm EST (3am UTC), Slicer build bots (aka factories)
 will build, test and package Slicer application and all its extensions on Linux, MacOSX
-and Windows. Results are published daily on [CDash](http://slicer.cdash.org/index.php?project=Slicer4)
+and Windows. Results are published daily on `CDash <http://slicer.cdash.org/index.php?project=Slicer4>`_
 and developers introducing changes introducing build or test failures are notified by
 email.
 
 
-#### Decision-making process
+Decision-making process
+~~~~~~~~~~~~~~~~~~~~~~~
 
-1. Given the topic of interest, initiate discussion on the [mailing list](http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel).
+1. Given the topic of interest, initiate discussion on the `mailing list <http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel>`_.
 
 2. Identify a small circle of community members that are interested to study the
    topic in more depth.
 
 3. Take the discussion off the general list, work on the analysis of options and
-   alternatives, summarize findings on the wiki or similar. [Labs](https://www.slicer.org/wiki/Documentation/Labs)
+   alternatives, summarize findings on the wiki or similar. `Labs <https://www.slicer.org/wiki/Documentation/Labs>`_
    page are usually a good ground for such summary.
 
 4. Announce on the mailing list the in-depth discussion of the topic for the
-   [Slicer Community hangout](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Meetings),
+   `Slicer Community hangout <https://www.slicer.org/wiki/Documentation/Nightly/Developers/Meetings>`_,
    encourage anyone that is interested in weighing in on the topic to join the
    discussion. If there is someone who is interested to participate in the discussion,
    but cannot join the meeting due to conflict, they should notify the leaders of
@@ -112,12 +120,13 @@ email.
 5. Hopefully, reach consensus at the hangout and proceed with the agreed plan.
 
 
-*The initial version of these guidelines was established during the [winter
- project week 2017](http://www.na-mic.org/Wiki/index.php/2017_Winter_Project_Week/UpdatingCommunityForums).*
+`The initial version of these guidelines was established during the [winter
+project week 2017](http://www.na-mic.org/Wiki/index.php/2017_Winter_Project_Week/UpdatingCommunityForums).`
 
-#### Benevolent dictators for life
+Benevolent dictators for life
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The [benevolent dictators](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) can
+The `benevolent dictators <https://en.wikipedia.org/wiki/Benevolent_dictator_for_life>`_ can
 integrate changes to keep the platform healthy and help interpret
 or address conflict related to the contribution guidelines.
 

Docs/Makefile

@@ -0,0 +1,20 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+SPHINXPROJ    = 3DSlicer
+SOURCEDIR     = .
+BUILDDIR      = _build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

Docs/conf.py

@@ -0,0 +1,166 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8 -*-
+#
+# 3D Slicer documentation build configuration file, created by
+# sphinx-quickstart on Tue Mar 21 03:07:30 2017.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#
+import os
+# import sys
+# sys.path.insert(0, os.path.abspath('.'))
+
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#
+# needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+#
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = '3D Slicer'
+copyright = '2017, Slicer Community'
+author = 'Slicer Community'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = ''
+# The full version, including alpha/beta/rc tags.
+release = ''
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This patterns also effect to html_static_path and html_extra_path
+exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+#
+html_theme = 'default'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#
+# html_theme_options = {}
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+
+# -- Options for HTMLHelp output ------------------------------------------
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = '3DSlicerdoc'
+
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+    # The paper size ('letterpaper' or 'a4paper').
+    #
+    # 'papersize': 'letterpaper',
+
+    # The font size ('10pt', '11pt' or '12pt').
+    #
+    # 'pointsize': '10pt',
+
+    # Additional stuff for the LaTeX preamble.
+    #
+    # 'preamble': '',
+
+    # Latex figure (float) alignment
+    #
+    # 'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+    (master_doc, '3DSlicer.tex', '3D Slicer Documentation',
+     'Slicer Community', 'manual'),
+]
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, '3Dslicer', '3D Slicer Documentation',
+     [author], 1)
+]
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (master_doc, '3DSlicer', '3D Slicer Documentation',
+     author, '3DSlicer', 'One line description of project.',
+     'Miscellaneous'),
+]
+
+
+# -- Read The Docs -----------------------------------------------------
+
+# on_rtd is whether we are on readthedocs.io
+on_rtd = os.environ.get('READTHEDOCS', None) == 'True'
+
+if not on_rtd:  # only import and set the theme if we're building docs locally
+    import sphinx_rtd_theme
+    html_theme = 'sphinx_rtd_theme'
+    html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+

Docs/developer_guide/authors.rst

@@ -0,0 +1 @@
+.. include:: ../../AUTHORS.rst

Docs/developer_guide/contributing.rst

@@ -0,0 +1 @@
+.. include:: ../../CONTRIBUTING.rst