added titles; fixed a few typos

docs/content/About-Experimental-Features.md

@@ -1,4 +1,5 @@
 ---
 layout: doc_page
 ---
-Experimental features are features we have developed but have not fully tested in a production environment. If you choose to try them out, there will likely to edge cases that we have not covered. We would love feedback on any of these features, whether they are bug reports, suggestions for improvement, or letting us know they work as intended.
+# About Experimental Features
+Experimental features are features we have developed but have not fully tested in a production environment. If you choose to try them out, there will likely be edge cases that we have not covered. We would love feedback on any of these features, whether they are bug reports, suggestions for improvement, or letting us know they work as intended.

docs/content/Aggregations.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Aggregations
 Aggregations are specifications of processing over metrics available in Druid.
 Available aggregations are:
 

docs/content/Deep-Storage.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Deep Storage
 Deep storage is where segments are stored.  It is a storage mechanism that Druid does not provide.  This deep storage infrastructure defines the level of durability of your data, as long as Druid nodes can see this storage infrastructure and get at the segments stored on it, you will not lose data no matter how many Druid nodes you lose.  If segments disappear from this storage layer, then you will lose whatever data those segments represented.
 
 The currently supported types of deep storage follow.

docs/content/DimensionSpecs.md

@@ -1,6 +1,8 @@
 ---
 layout: doc_page
 ---
+# Transforming Dimension Values
+The following JSON fields can be used in a query to operate on dimension values. 
 
 ## DimensionSpec
 
@@ -8,7 +10,7 @@ layout: doc_page
 
 ### DefaultDimensionSpec
 
-Returns dimension values as is and optionally renames renames the dimension.
+Returns dimension values as is and optionally renames the dimension.
 
 ```json
 { "type" : "default", "dimension" : <dimension>, "outputName": <output_name> }

docs/content/Filters.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+#Query Filters
 A filter is a JSON object indicating which rows of data should be included in the computation for a query. It’s essentially the equivalent of the WHERE clause in SQL. Druid supports the following types of filters.
 
 ### Selector filter
@@ -78,4 +79,4 @@ The following matches any dimension values for the dimension `name` between `'ba
   "dimension" : "name",
   "function" : "function(x) { return(x >= 'bar' && x <= 'foo') }"
 }
-```
+```

docs/content/GeographicQueries.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Geographic Queries
 Druid supports filtering specially spatially indexed columns based on an origin and a bound.
 
 # Spatial Indexing

docs/content/Granularities.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Aggregation Granularity
 The granularity field determines how data gets bucketed across the time dimension, i.e how it gets aggregated by hour, day, minute, etc.
 
 It can be specified either as a string for simple granularities or as an object for arbitrary granularities.

docs/content/GroupByQuery.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# groupBy Queries
 These types of queries take a groupBy query object and return an array of JSON objects where each object represents a grouping asked for by the query. Note: If you only want to do straight aggreagates for some time range, we highly recommend using [TimeseriesQueries](TimeseriesQuery.html) instead. The performance will be substantially better.
 An example groupBy query object is shown below:
 
@@ -86,4 +87,4 @@ To pull it all together, the above query would return *n\*m* data points, up to
   },
 ...
 ]
-```
+```

docs/content/Having.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Filter groupBy Query Results
 A having clause is a JSON object identifying which rows from a groupBy query should be returned, by specifying conditions on aggregated values.
 
 It is essentially the equivalent of the HAVING clause in SQL.

docs/content/Indexing-Service.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Druid Indexing Service
 The indexing service is a highly-available, distributed service that runs indexing related tasks. Indexing service [tasks](Tasks.html) create (and sometimes destroy) Druid [segments](Segments.html). The indexing service has a master/slave like architecture.
 
 The indexing service is composed of three main components: a peon component that can run a single task, a [Middle Manager](Middlemanager.html) component that manages peons, and an overlord component that manages task distribution to middle managers.

docs/content/MySQL.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# MySQL Database
 MySQL is an external dependency of Druid. We use it to store various metadata about the system, but not to store the actual data. There are a number of tables used for various purposes described below.
 
 Segments Table

docs/content/OrderBy.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Sort groupBy Query Results
 The orderBy field provides the functionality to sort and limit the set of results from a groupBy query. If you group by a single dimension and are ordering by a single metric, we highly recommend using [TopN Queries](TopNQuery.html) instead. The performance will be substantially better. Available options are:
 
 ### DefaultLimitSpec

docs/content/Post-aggregations.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Post-Aggregations
 Post-aggregations are specifications of processing that should happen on aggregated values as they come out of Druid. If you include a post aggregation as part of a query, make sure to include all aggregators the post-aggregator requires.
 
 There are several post-aggregators available.

docs/content/Rule-Configuration.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Configuring Rules for Coordinator Nodes
 Note: It is recommended that the coordinator console is used to configure rules. However, the coordinator node does have HTTP endpoints to programmatically configure rules.
 
 Load Rules

docs/content/SearchQuery.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Search Queries
 A search query returns dimension values that match the search specification.
 
 ```json

docs/content/SearchQuerySpec.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Refining Search Queries
 Search query specs define how a "match" is defined between a search value and a dimension value. The available search query specs are:
 
 InsensitiveContainsSearchQuerySpec

docs/content/SegmentMetadataQuery.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Segment Metadata Queries
 Segment metadata queries return per segment information about:
 
 * Cardinality of all columns in the segment

docs/content/Tasks.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Tasks
 Tasks are run on middle managers and always operate on a single data source.
 
 There are several different types of tasks.

docs/content/TimeBoundaryQuery.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Time Boundary Queries
 Time boundary queries return the earliest and latest data points of a data set. The grammar is:
 
 ```json

docs/content/Versioning.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# Versioning Druid
 This page discusses how we do versioning and provides information on our stable releases.
 
 Versioning Strategy

docs/content/ZooKeeper.md

@@ -1,6 +1,7 @@
 ---
 layout: doc_page
 ---
+# ZooKeeper
 Druid uses [ZooKeeper](http://zookeeper.apache.org/) (ZK) for management of current cluster state. The operations that happen over ZK are
 
 1.  [Coordinator](Coordinator.html) leader election