Change two blanks to one blank after numbered list item

website/source/docs/extend/developing-plugins.html.markdown

@@ -60,10 +60,10 @@ dependencies.
 
 There are two steps involved in creating a plugin:
 
-1.  Implement the desired interface. For example, if you're building a builder
+1. Implement the desired interface. For example, if you're building a builder
   plugin, implement the `packer.Builder` interface.
 
-2.  Serve the interface by calling the appropriate plugin serving method in your
+2. Serve the interface by calling the appropriate plugin serving method in your
   main method. In the case of a builder, this is `plugin.ServeBuilder`.
 
 A basic example is shown below. In this example, assume the `Builder` struct

website/source/docs/extend/plugins.html.markdown

@@ -51,12 +51,12 @@ Once the plugin is named properly, Packer automatically discovers plugins in the
 following directories in the given order. If a conflicting plugin is found
 later, it will take precedence over one found earlier.
 
-1.  The directory where `packer` is, or the executable directory.
+1. The directory where `packer` is, or the executable directory.
 
-2.  `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d/plugins`
+2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d/plugins`
   on Windows.
 
-3.  The current working directory.
+3. The current working directory.
 
 The valid types for plugins are:
 

website/source/docs/post-processors/atlas.html.markdown

@@ -25,13 +25,13 @@ location in Atlas.
 
 Here is an example workflow:
 
-1.  Packer builds an AMI with the [Amazon AMI
+1. Packer builds an AMI with the [Amazon AMI
   builder](/docs/builders/amazon.html)
-2.  The `atlas` post-processor takes the resulting AMI and uploads it to Atlas.
+2. The `atlas` post-processor takes the resulting AMI and uploads it to Atlas.
   The `atlas` post-processor is configured with the name of the AMI, for example
   `hashicorp/foobar`, to create the artifact in Atlas or update the version if
   the artifact already exists
-3.  The new version is ready and available to be used in deployments with a tool
+3. The new version is ready and available to be used in deployments with a tool
   like [Terraform](https://terraform.io)
 
 ## Configuration

website/source/docs/post-processors/vagrant-cloud.html.markdown

@@ -36,16 +36,16 @@ and deliver them to your team in some fashion.
 
 Here is an example workflow:
 
-1.  You use Packer to build a Vagrant Box for the `virtualbox` provider
-2.  The `vagrant-cloud` post-processor is configured to point to the box
+1. You use Packer to build a Vagrant Box for the `virtualbox` provider
+2. The `vagrant-cloud` post-processor is configured to point to the box
   `hashicorp/foobar` on Vagrant Cloud via the `box_tag` configuration
-3.  The post-processor receives the box from the `vagrant` post-processor
-4.  It then creates the configured version, or verifies the existence of it, on
+3. The post-processor receives the box from the `vagrant` post-processor
+4. It then creates the configured version, or verifies the existence of it, on
   Vagrant Cloud
-5.  A provider matching the name of the Vagrant provider is then created
-6.  The box is uploaded to Vagrant Cloud
-7.  The upload is verified
-8.  The version is released and available to users of the box
+5. A provider matching the name of the Vagrant provider is then created
+6. The box is uploaded to Vagrant Cloud
+7. The upload is verified
+8. The version is released and available to users of the box
 
 ## Configuration