DOC Moves under review to top level toc (#40)

Author: jnothman

index.rst

@@ -9,7 +9,9 @@
     :maxdepth: 1
     :caption: Under review
 
-    under_review
+    slep007/proposal
+    slep012/proposal
+    slep013/proposal
 
 .. toctree::
     :maxdepth: 1

slep007/proposal.rst

@@ -1,8 +1,8 @@
  .. _slep_007:
 
-===========================================
-Feature names, their generation and the API
-===========================================
+====================================================
+SLEP007: Feature names, their generation and the API
+====================================================
 
 :Author: Adrin Jalali
 :Status: Under Review

slep012/proposal.rst

@@ -1,16 +1,16 @@
 .. _slep_012:
 
-==========
-InputArray
-==========
+=======================
+SLEP012: ``InputArray``
+=======================
 
 :Author: Adrin jalali
 :Status: Draft
 :Type: Standards Track
 :Created: 2019-12-20
 
 Motivation
-**********
+##########
 
 This proposal results in a solution to propagating feature names through
 transformers, pipelines, and the column transformer. Ideally, we would have::
@@ -39,7 +39,7 @@ transformer, would not break. This SLEP focuses on *feature names* as the only
 meta-data attached to the data. Support for other meta-data can be added later.
 
 Backward/NumPy/Pandas Compatibility
-***********************************
+###################################
 
 Since currently transformers return a ``numpy`` or a ``scipy`` array, backward
 compatibility in this context means the operations which are valid on those
@@ -59,13 +59,13 @@ which ``pandas`` does not provide a clean API at the moment. Alternatively,
 relevant meta-data attached.
 
 Feature Names
-*************
+#############
 
 Feature names are an object ``ndarray`` of strings aligned with the columns.
 They can be ``None``.
 
 Operations
-**********
+##########
 
 Estimators understand the ``InputArray`` and extract the feature names from the
 given data before applying the operations and transformations on the data.
@@ -75,20 +75,20 @@ The way feature names are generated is discussed in *SLEP007 - The Style of The
 Feature Names*.
 
 Sparse Arrays
-*************
+#############
 
 Ideally sparse arrays follow the same pattern, but since ``scipy.sparse`` does
 not provide the kinda of API provided by ``numpy``, we may need to find
 compromises.
 
 Factory Methods
-***************
+###############
 
 There will be factory methods creating an ``InputArray`` given a
 ``pandas.DataFrame`` or an ``xarray.DataArray`` or simply an ``np.ndarray`` or
 an ``sp.SparseMatrix`` and a given set of feature names.
 
-An ``InputArray`` can also be converted to a `pandas.DataFrame`` using a
+An ``InputArray`` can also be converted to a ``pandas.DataFrame`` using a
 ``todataframe()`` method.
 
 ``X`` being an ``InputArray``::
@@ -103,7 +103,7 @@ feature names, one can make the right ``InputArray`` using::
     >>> make_inputarray(X, feature_names)
 
 Alternative Solutions
-*********************
+#####################
 
 Since we expect the feature names to be attached to the data given to an
 estimator, there are a few potential approaches we can take:
@@ -114,7 +114,7 @@ estimator, there are a few potential approaches we can take:
   is not a feasible solution since ``pandas`` plans to move to a per column
   representation, which means ``pd.DataFrame(np.asarray(df))`` has two
   guaranteed memory copies.
-- ``XArray``: we could accept a `pandas.DataFrame``, and use
+- ``XArray``: we could accept a ``pandas.DataFrame``, and use
   ``xarray.DataArray`` as the output of transformers, including feature names.
   However, ``xarray`` has a hard dependency on ``pandas``, and uses
   ``pandas.Index`` to handle row labels and aligns rows when an operation