Configuration, templates and wording

Reusing much from https://github.com/ghc-proposals/ghc-proposals.

Author: ehigham

Diff for: .gitignore

@@ -0,0 +1,2 @@
+_build
+_venv

Diff for: Makefile

@@ -0,0 +1,20 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+SPHINXPROJ    = hail-proposals
+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)

Diff for: README.md

@@ -0,0 +1,153 @@
+# -*- coding: utf-8 -*-
+#
+# Configuration file for the Sphinx documentation builder.
+#
+# This file does only contain a selection of the most common options. For a
+# full list see the documentation:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+
+# -- Path setup --------------------------------------------------------------
+
+# 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('.'))
+
+
+# -- Project information -----------------------------------------------------
+
+project = u'hail-rfc'
+copyright = u'2023, Broad Institute'
+author = u''
+
+# The short X.Y version
+version = u''
+# The full version, including alpha/beta/rc tags
+release = u''
+
+
+# -- 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 main toctree document.
+main_doc = 'index'
+
+# 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 pattern also affects html_static_path and html_extra_path .
+exclude_patterns = [u'_build', 'Thumbs.db', '.DS_Store', "rfc/0000-template.rst"]
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+
+# -- 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 = 'haiku'
+
+# 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']
+
+# Custom sidebar templates, must be a dictionary that maps document names
+# to template names.
+#
+# The default sidebars (for documents that don't match any pattern) are
+# defined by theme itself.  Builtin themes are using these templates by
+# default: ``['localtoc.html', 'relations.html', 'sourcelink.html',
+# 'searchbox.html']``.
+#
+# html_sidebars = {}
+
+
+# -- Options for HTMLHelp output ---------------------------------------------
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'hail-proposalsdoc'
+
+
+# -- 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 = [
+    (main_doc, 'hail-proposals.tex', u'Hail Proposals', u'Hail', 'manual'),
+]
+
+
+# -- Options for manual page output ------------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (main_doc, 'hail-proposals', u'Hail Proposals', [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 = [
+    (main_doc, 'hail-proposals', u'Hail Proposals',
+     author, 'hail-proposals', 'One line description of project.',
+     'Miscellaneous'),
+]

Diff for: README.rst

@@ -0,0 +1,19 @@
+All accepted Hail Proposals
+==========================
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents:
+   :glob:
+
+   README.rst
+   hail.rst
+   rfc/*
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`

Diff for: conf.py

@@ -0,0 +1,126 @@
+Notes on reStructuredText - delete this section before submitting
+==================================================================
+
+The proposals are submitted in reStructuredText format.
+To get inline code, enclose text in double backticks, ``like this``, or include
+inline syntax highlighting [scala]`like this`.
+To get block code, use a double colon and indent by at least one space
+
+::
+
+ like this
+ and
+
+ this too
+
+To get hyperlinks, use backticks, angle brackets, and an underscore
+`like this <http://www.hail.is/>`_.
+
+==============
+Proposal title
+==============
+
+.. author:: Your name
+.. date-accepted:: Leave blank. This will be filled in when the proposal is accepted.
+.. ticket-url:: Leave blank. This will eventually be filled with the
+                ticket URL which will track the progress of the
+                implementation of the feature.
+.. implemented:: Leave blank. This will be filled in with the first Hail version which
+                 implements the described feature.
+.. header:: This proposal is `discussed at this pull request <https://github.com/hail-is/hail-rfc/pull/0>`_.
+            **After creating the pull request, edit this file again, update the
+            number in the link, and delete this bold sentence.**
+.. sectnum::
+.. contents::
+.. role:: scala(code)
+
+Here you should write a short abstract motivating and briefly summarizing the
+proposed change.
+
+Motivation
+----------
+Give a strong reason for why the community needs this change. Describe the use
+case as clearly as possible and give an example. Explain how the status quo is
+insufficient or not ideal.
+
+A good Motivation section is often driven by examples and real-world scenarios.
+
+Proposed Change Specification
+-----------------------------
+Specify the change in precise, comprehensive yet concise language. Avoid words
+like "should" or "could". Strive for a complete definition. Your specification
+may include,
+
+* the types and semantics of any new library interfaces
+* how the proposed change interacts with existing language or compiler
+  features, in case that is otherwise ambiguous
+
+Strive for *precision*. Note, however, that this section should focus on a
+precise *specification*; it need not (and should not) devote space to
+*implementation* details -- the "Implementation Plan" section can be used for
+that.
+
+The specification can, and almost always should, be illustrated with
+*examples* that illustrate corner cases. But it is not sufficient to
+give a couple of examples and regard that as the specification! The
+examples should illustrate and elucidate a clearly-articulated
+specification that covers the general case.
+
+Examples
+--------
+This section illustrates the specification through the use of examples of the
+language change proposed. It is best to exemplify each point made in the
+specification, though perhaps one example can cover several points. Contrived
+examples are OK here. If the Motivation section describes something that is
+hard to do without this proposal, this is a good place to show how easy that
+thing is to do with the proposal.
+
+Effect and Interactions
+-----------------------
+Your proposed change addresses the issues raised in the motivation. Explain how.
+
+Also, discuss possibly contentious interactions with existing language or compiler
+features. Complete this section with potential interactions raised
+during the PR discussion.
+
+Costs and Drawbacks
+-------------------
+Give an estimate on development and maintenance costs. List how this affects
+learnability of the language for novice users. Define and list any remaining
+drawbacks that cannot be resolved.
+
+Alternatives
+------------
+List alternative designs to your proposed change. Both existing
+workarounds, or alternative choices for the changes. Explain
+the reasons for choosing the proposed change over these alternative:
+*e.g.* they can be cheaper but insufficient, or better but too
+expensive. Or something else.
+
+The PR discussion often raises other potential designs, and they should be
+added to this section. Similarly, if the proposed change
+specification changes significantly, the old one should be listed in
+this section.
+
+Unresolved Questions
+--------------------
+Explicitly list any remaining issues that remain in the conceptual design and
+specification. Be upfront and trust that the community will help. Please do
+not list *implementation* issues.
+
+Hopefully this section will be empty by the time the proposal is brought to
+the steering committee.
+
+Implementation Plan
+-------------------
+(Optional) If accepted who will implement the change? Which other resources
+and prerequisites are required for implementation?
+
+Endorsements
+-------------
+(Optional) This section provides an opportunity for any third parties to express their
+support for the proposal, and to say why they would like to see it adopted.
+It is not mandatory for have any endorsements at all, but the more substantial
+the proposal is, the more desirable it is to offer evidence that there is
+significant demand from the community.  This section is one way to provide
+such evidence.

Diff for: index.rst

@@ -0,0 +1,15 @@
+#!/bin/sh
+
+if [ -z "$SHELL" ]; then
+	SHELL=/bin/sh
+fi
+
+if [ ! -d _venv ]; then
+	virtualenv _venv
+	. _venv/bin/activate
+	pip install sphinx
+	exec $SHELL
+else
+	. _venv/bin/activate
+	exec $SHELL
+fi