update docs

docs/conventions.rst

@@ -5,7 +5,7 @@ Conventions
 data organization, and data normalization. Understanding these conventions
 makes **finagg** a bit more ergonomic. This page covers those conventions.
 
-Import conventions
+Import Conventions
 ------------------
 
 Following **finagg**'s import conventions guarantees updates to **finagg**
@@ -31,7 +31,7 @@ It's also common for subpackages to be imported using their name as an alias:
 >>> import finagg.fred as fred
 >>> import finagg.sec as sec
 
-Package organization
+Package Organization
 --------------------
 
 **finagg** is organized according to API implementations, SQL table
@@ -63,7 +63,7 @@ because there is no use for further transforming or normalizing the data
 available through :mod:`finagg.indices.api` or defined by
 :mod:`finagg.indices.sql`.
 
-API implementations
+API Implementations
 -------------------
 
 APIs are implemented as singleton class instances within ``api`` submodules
@@ -103,13 +103,13 @@ Other implemented APIs, such as the SEC EDGAR API implemented by
 :mod:`finagg.sec.api`, don't have as many helper methods and are barebone
 implementations.
 
-Almost everything is a dataframe
+Almost Everything is a Dataframe
 --------------------------------
 
 Dataframes are just too convenient to not use as the fundamental type within
 **finagg**. Almost all objects returned by APIs and features are dataframes.
 
-Helper methods for inspecting available data
+Helper Methods for Inspecting Available Data
 --------------------------------------------
 
 Most submodules and singletons contain helper methods for getting sets of
@@ -124,7 +124,7 @@ further refinement. Examples of these methods include:
 * :meth:`finagg.sec.feat.Quarterly.get_ticker_set` returns all the tickers
   that have quarterly features available
 
-Data organization
+Data Organization
 -----------------
 
 There are only a handful of conventions regarding data organization:
@@ -140,7 +140,7 @@ There are only a handful of conventions regarding data organization:
   have foreign key constraints on raw data SQL tables such that refined rows
   are deleted when raw rows are deleted with the same primary key.
 
-Data normalization
+Data Normalization
 ------------------
 
 Data returned by API implementations is not normalized or standardized
@@ -164,7 +164,7 @@ rules implemented for data normalization are as follows:
   granular to most granular (e.g., year -> quarter -> date). Indices
   are always sorted.
 
-Feature method naming
+Feature Method Naming
 ---------------------
 
 Features are aggregations or collections of raw and/or refined data that're

docs/installation.rst

@@ -1,19 +1,28 @@
 Installation
 ============
 
+Installing from PyPI
+--------------------
+
 Install with pip for the latest stable version.
 
 .. code:: console
 
   pip install finagg
 
+Installing from GitHub
+----------------------
+
 Install from GitHub for the latest unstable version.
 
 .. code:: console
 
     git clone https://github.com/theOGognf/finagg.git
     pip install ./finagg/
 
+Installing Datasets
+-------------------
+
 Optionally install the recommended datasets (economic data, company
 financials, stock histories, etc.) from 3rd party APIs into a local SQL
 database.

docs/walkthroughs.rst

@@ -20,6 +20,9 @@ environment.
 Using the FRED API Subpackages
 ------------------------------
 
+Searching for economic data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 Let's say we're interested in finding economic data series corresponding
 to various US treasuries. The FRED series search API is a good place to start.
 The FRED series search API allows us to search through economic data series
@@ -50,6 +53,9 @@ key info for further exploring and aggregating the economic data series:
 * the ``observation_start`` column indicates the oldest date with data for
   each series (we may want to ignore series that don't have as much history)
 
+Retrieving economic data
+^^^^^^^^^^^^^^^^^^^^^^^^
+
 Let's assume we're only interested in the economic data series corresponding
 to economic series ID ``"DGS10"`` under the ``id`` column. We can get the
 economic data series observations through the FRED series observations API
@@ -85,6 +91,9 @@ series (and most treasury yield series), the ``realtime_start`` and
 ``realtime_end`` parameters must be today's date (the default) and the
 ``output_type`` parameter must be ``1`` (also the default).
 
+Installing economic data
+^^^^^^^^^^^^^^^^^^^^^^^^
+
 So now we have an economic data series we're interested in and can retrieve
 observation values for. We can download and store (or install) the economic
 data series observation values in our own SQL table to reduce the number of
@@ -180,6 +189,9 @@ is equivalent to:
 Using the SEC API Subpackages
 -----------------------------
 
+Retrieving company financial data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 Let's say we're interested in a specific company. The SEC EDGAR API is a good
 place to start accessing a company's financials. However, not all companies
 have all their financial data accessible through the SEC EDGAR API. The best
@@ -226,8 +238,11 @@ with the following:
 3  2007-07-01  2008-06-30   1.90  0001193125-10-171791  2010  FY  10-K  2010-07-30 ...
 4  2008-04-01  2008-06-30   0.46  0001193125-10-171791  2010  FY  10-K  2010-07-30 ...
 
+Filtering company financial data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 However, the SEC EDGAR company concept API implementation returns all the
-earnings per share publications for Microsft, including amendments. We may
+earnings per share publications for Microsoft, including amendments. We may
 not necessarily care about amendments because we may be building strategies
 or models that use *current* data and not *future* data. Fortunately, **finagg**
 provides :meth:`finagg.sec.api.get_unique_filings` to further select
@@ -245,19 +260,20 @@ Unfortunately, the SEC EDGAR API is still relatively new and a lot of the
 financial data publications are unaudited, so not all financials are available
 for all companies through the SEC EDGAR API. I.e., a workflow for retrieving
 Microsoft's financial data may not work for retrieving another company's
-financial data. It requires some trial-and-error to find a set of tags that
+financial data.
+
+It requires some trial-and-error to find a set of tags that
 are popular and available for the majority of companies. In addition, the
 workflow for exploring these tags and filtering forms can be cumbersome.
+However, **finagg** provides :data:`finagg.sec.api.popular_concepts` for listing
+company concepts (combinations of financial data tags and other parameters)
+that're popular and widely available for companies.
 
-Fortunately again, **finagg** exists for a reason besides implementing these
-useful APIs. **finagg** provides additional conveniences that makes these
-common workflows even easier.
+Installing company financial data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-First, **finagg** provides :data:`finagg.sec.api.popular_concepts` for listing
-company concepts (combinations of financial data tags and other parameters)
-that're popular and widely available for companies. Second, it's extremely
-straightforward to filter and install widely popular and available quarterly
-financial data for a set of companies using the :mod:`finagg.sec.feat`
+It's extremely straightforward to filter and install widely popular and available
+quarterly financial data for a set of companies using the :mod:`finagg.sec.feat`
 subpackage and :data:`finagg.sec.feat.quarterly` member. The
 :data:`finagg.sec.feat.quarterly` member also goes a step further by somewhat
 normalizing the installed financial data (e.g., total asset value is converted