Rename .markdown to .md and move Contributing.md

The prevailing convention on GitHub seems to be .md

Also by moving CONTRIBUTING.md to the root, GitHub will automatically
link to it when someone tries to contribute:

https://github.com/blog/1184-contributing-guidelines

CONTRIBUTING.md

@@ -6,7 +6,7 @@ changes, you'll need to follow a similar set of processes and rules that the
 Vitess team follows.
 
 ### Prerequisites
-  - [Install vitess](https://github.com/youtube/vitess/blob/master/doc/GettingStarted.markdown)
+  - [Install vitess](https://github.com/youtube/vitess/blob/master/doc/GettingStarted.md)
   - The vitess team uses appspot for code reviews. You'll need to create an account at http://codereview.appspot.com.
   - Fork the vitess repository, say https://github.com/myfork/vitess.
   - Download [upload.py](https://code.google.com/p/rietveld/wiki/UploadPyUsage) and put it in your path.

README.md

@@ -5,7 +5,7 @@ databases for the web. It's been developed since 2011, and is currently used as
 a fundamental component of YouTube's MySQL infrastructure, serving thousands of
 QPS (per server). If you want to find out whether Vitess is a good fit for your
 project, please read our [helicopter
-overview](https://github.com/youtube/vitess/blob/master/doc/HelicopterOverview.markdown).
+overview](https://github.com/youtube/vitess/blob/master/doc/HelicopterOverview.md).
 
 There are a couple of videos from [sougou](https://github.com/sougou) that you can watch:
 a [short intro](http://youtu.be/midJ6b1LkA0) prepared for Google I/O 2014
@@ -55,40 +55,40 @@ undocumented. However, if you feel adventurous, you're more than welcome to try
 it. We know that there are some rough edges, so please don't hesitate to reach out
 to us through [our mailing list](https://groups.google.com/forum/#!forum/vitess)
 if you run into any issues. Warnings aside, please take a look at our [Getting
-Started](https://github.com/youtube/vitess/blob/master/doc/GettingStarted.markdown)
+Started](https://github.com/youtube/vitess/blob/master/doc/GettingStarted.md)
 guide.
 
 ## Documentation
 
 ### Intro
- * [Helicopter overview](https://github.com/youtube/vitess/blob/master/doc/HelicopterOverview.markdown):
+ * [Helicopter overview](https://github.com/youtube/vitess/blob/master/doc/HelicopterOverview.md):
      high level overview of Vitess that should tell you whether Vitess is for you.
- * [Frequently Asked Questions](https://github.com/youtube/vitess/blob/master/doc/FAQ.markdown).
- * [Vision](https://github.com/youtube/vitess/blob/master/doc/Vision.markdown):
+ * [Frequently Asked Questions](https://github.com/youtube/vitess/blob/master/doc/FAQ.md).
+ * [Vision](https://github.com/youtube/vitess/blob/master/doc/Vision.md):
      principles guiding the design of Vitess.
 
 ### Using Vitess
 
- * [Getting Started](https://github.com/youtube/vitess/blob/master/doc/GettingStarted.markdown):
+ * [Getting Started](https://github.com/youtube/vitess/blob/master/doc/GettingStarted.md):
      how to set your environment to work with Vitess.
- * [Tools](https://github.com/youtube/vitess/blob/master/doc/Tools.markdown):
+ * [Tools](https://github.com/youtube/vitess/blob/master/doc/Tools.md):
      all Vitess tools and servers.
- * [Vttablet](https://github.com/youtube/vitess/blob/master/doc/Vttablet.markdown):
+ * [Vttablet](https://github.com/youtube/vitess/blob/master/doc/Vttablet.md):
      information about the most important Vitess server.
- * [Reparenting](https://github.com/youtube/vitess/blob/master/doc/Reparenting.markdown):
+ * [Reparenting](https://github.com/youtube/vitess/blob/master/doc/Reparenting.md):
      performing master failover.
- * [Resharding](https://github.com/youtube/vitess/blob/master/doc/Resharding.markdown):
+ * [Resharding](https://github.com/youtube/vitess/blob/master/doc/Resharding.md):
      adding more shards to your cluster.
- * [Preparing for production](https://github.com/youtube/vitess/blob/master/doc/Production.markdown) (wip).
- * [Schema management](https://github.com/youtube/vitess/blob/master/doc/SchemaManagement.markdown):
+ * [Preparing for production](https://github.com/youtube/vitess/blob/master/doc/Production.md) (wip).
+ * [Schema management](https://github.com/youtube/vitess/blob/master/doc/SchemaManagement.md):
      managing your database schema using Vitess.
 
 ### Reference
 
- * [General Concepts](https://github.com/youtube/vitess/blob/master/doc/Concepts.markdown)
- * [Zookeeper data](https://github.com/youtube/vitess/blob/master/doc/ZookeeperData.markdown)
- * [Serving graph](https://github.com/youtube/vitess/blob/master/doc/ServingGraph.markdown)
- * [Replication Graph](https://github.com/youtube/vitess/blob/master/doc/ReplicationGraph.markdown)
+ * [General Concepts](https://github.com/youtube/vitess/blob/master/doc/Concepts.md)
+ * [Zookeeper data](https://github.com/youtube/vitess/blob/master/doc/ZookeeperData.md)
+ * [Serving graph](https://github.com/youtube/vitess/blob/master/doc/ServingGraph.md)
+ * [Replication Graph](https://github.com/youtube/vitess/blob/master/doc/ReplicationGraph.md)
 
 ## License
 

doc/Concepts.md

@@ -20,7 +20,7 @@ modulo some replication lag).
 
 A Keyspace usually has one shard when not using any sharding (we name it '0' by convention). When sharded, a Keyspace will have N shards (usually, N is a power of 2) with non-overlapping data.
 
-We support [dynamic resharding](Resharding.markdown), when one shard is split into 2 shards for instance. In this case, the data in the
+We support [dynamic resharding](Resharding.md), when one shard is split into 2 shards for instance. In this case, the data in the
 source shard is duplicated into the 2 destination shards, but only during the transition. Afterwards, the source shard is
 deleted.
 
@@ -85,14 +85,14 @@ and a hashed version of that UserId as a keyspace_id. All data related to one us
 the same shard, as all rows will share that keyspace_id.
 
 ### Replication graph
-The [Replication Graph](ReplicationGraph.markdown) represents the relationships between the master
+The [Replication Graph](ReplicationGraph.md) represents the relationships between the master
 databases and their respective replicas.
 This data is particularly useful during a master failover.
 Once a new master has been designated, all existing replicas have to
 repointed to the new master so that replication can resume.
 
 ### Serving graph
-The [Serving Graph](ServingGraph.markdown) is derived from the shard and replication graph.
+The [Serving Graph](ServingGraph.md) is derived from the shard and replication graph.
 It represens the list of active servers that are available to serve
 queries.
 VTGate (or smart clients) query the serving graph to find out which servers

doc/GettingStarted.md

@@ -76,7 +76,7 @@ pkill -f '(vtdataroot|VTDATAROOT)' # kill Vitess processes
 #### Too many connections to MySQL, or other timeouts
 
 This often means your disk is too slow. If you don't have access to an SSD,
-you can try [testing against a ramdisk](TestingOnARamDisk.markdown).
+you can try [testing against a ramdisk](TestingOnARamDisk.md).
 
 #### Connection refused to tablet, MySQL socket not found, etc.
 

doc/ReplicationGraph.md

@@ -26,4 +26,4 @@ If a cell is down, the result is partial. Some actions are resilient to partial
 
 ## Reparenting
 
-[Reparenting](Reparenting.markdown) will update the MasterAlias record in the Shard (after having acquired the Shard lock). See the Reparenting doc for more information.
+[Reparenting](Reparenting.md) will update the MasterAlias record in the Shard (after having acquired the Shard lock). See the Reparenting doc for more information.

doc/TestingOnARamDisk.md

@@ -4,7 +4,7 @@ The `integration_test` testsuite contains tests that may time-out if run against
 
 # Setup
 
-First, set up a normal vitess development environment by running `bootstrap.sh` and sourcing `dev.env` (see [GettingStarted](GettingStarted.markdown)). Then overwrite the testing temporary directories and make a 2GiB ramdisk at the location of your choice (this example uses `/tmp/vt`):
+First, set up a normal vitess development environment by running `bootstrap.sh` and sourcing `dev.env` (see [GettingStarted](GettingStarted.md)). Then overwrite the testing temporary directories and make a 2GiB ramdisk at the location of your choice (this example uses `/tmp/vt`):
 
 ```sh
 export TEST_TMPDIR=/tmp/vt