diff --git a/doc/source/install/install-without-devstack.rst b/doc/source/install/install-without-devstack.rst
index 8889cf7d..e009f1db 100644
--- a/doc/source/install/install-without-devstack.rst
+++ b/doc/source/install/install-without-devstack.rst
@@ -117,7 +117,7 @@ And we need to create the reservation service in Keystone with its endpoints:
 
 .. sourcecode:: console
 
-    openstack service create --name blazar --description “OpenStack Reservation Service” reservation
+    openstack service create --name blazar --description "OpenStack Reservation Service" reservation
     openstack endpoint create --region <region> blazar admin "<auth_protocol>://<blazar_host>:<blazar_port>/v1"
     openstack endpoint create --region <region> blazar internal "<auth_protocol>://<blazar_host>:<blazar_port>/v1"
     openstack endpoint create --region <region> blazar public "<auth_protocol>://<blazar_host>:<blazar_port>/v1"
diff --git a/doc/source/user/architecture.rst b/doc/source/user/architecture.rst
index 759e0bf3..7816f224 100644
--- a/doc/source/user/architecture.rst
+++ b/doc/source/user/architecture.rst
@@ -69,7 +69,7 @@ Technically speaking, resource ID here will be not host ID, because there might
 be many of them wanted. Resource here will be new aggregate containing reserved
 hosts. The time lease starts, user may use reserved compute capacity to run
 his/her instances on it passing special scheduler hint to Nova. When host is
-reserved, it’s not used for usual instance running, it might be used only when
+reserved, it's not used for usual instance running, it might be used only when
 lease starts and only by passing reservation ID to Nova. That is implemented
 using special Nova Scheduler filter, that passes reservation ID to Blazar and
 checks if user really can use reserved compute capacity.
diff --git a/doc/source/user/introduction.rst b/doc/source/user/introduction.rst
index 987d07d0..dbcc5647 100644
--- a/doc/source/user/introduction.rst
+++ b/doc/source/user/introduction.rst
@@ -11,12 +11,12 @@ Idea of creating Blazar originated with two different use cases:
   to provide him working VM not necessarily now, but also in the future)
 
 Now these ideas have been transformed to more general view: with Blazar, user
-can request the resources of cloud environment to be provided (“leased”) to his
+can request the resources of cloud environment to be provided ("leased") to his
 project for specific amount of time, immediately or in the future.
 
 Both virtual (Instances, Volumes, Networks) and hardware (full hosts with
 specific characteristics of RAM, CPU, etc) resources can be allocated via
-“lease”.
+"lease".
 
 In terms of benefits added, Resource Reservation Service will: