more minor typo/grammar fixes

system/gui.md

@@ -73,7 +73,7 @@ Security markers on dom0 windows
 
 It is important that user knows which AppVM a given window belongs to. This prevents a rogue AppVM from painting a window pretending to belong to other AppVM or dom0 and trying to steal, for example, passwords.
 
-In Qubes, a custom window decorator is used that paints a colourful frame (the colour is determined during AppVM creation) around decorated windows. Additionally, the window title always starts with **[name of the AppVM]**. If a window has a *override_redirect* attribute, meaning that it should not be treated by a window manager (typical case is menu windows), *qubes_guid* draws a two-pixel colourful frame around it manually.
+In Qubes, a custom window decorator is used that paints a colourful frame (the colour is determined during AppVM creation) around decorated windows. Additionally, the window title always starts with **[name of the AppVM]**. If a window has an *override_redirect* attribute, meaning that it should not be treated by a window manager (typical case is menu windows), *qubes_guid* draws a two-pixel colourful frame around it manually.
 
 Clipboard sharing implementation
 --------------------------------
@@ -81,7 +81,7 @@ Clipboard sharing implementation
 Certainly, it would be insecure to allow AppVM to read/write the clipboards of other AppVMs unconditionally. 
 Therefore, the following mechanism is used:
 
--   there is a "qubes clipboard" in dom0 - its contents is stored in a regular file in dom0.
+-   there is a "qubes clipboard" in dom0 - its contents are stored in a regular file in dom0.
 -   if user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_REQ` message is sent to AppVM. *qubes-gui* responds with *CLIPBOARD_DATA* message followed by clipboard contents.
 -   user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the local clipboard, and then user can paste its contents to local applications normally.
 

system/storage-pools.md

@@ -7,31 +7,31 @@ permalink: /doc/storage-pools/
 Storage Pools in Qubes
 ======================
 
-Qubes OS R 3.2 introduced the concept of storage drivers & pools.  This feature
+Qubes OS R3.2 introduced the concept of storage drivers and pools.  This feature
 was a first step towards a saner storage API, which is heavily rewritten in R4.
 A storage driver provides a way to store VM images in a Qubes OS system.
 Currently, the default driver is `xen` which is the default way of storing
 volume images as files in a directory tree like `/var/lib/qubes/`.
 
-A pool storage driver can be identified either by the driver name with the
+A storage pool driver can be identified either by the driver name with the
 `driver` key or by the class name like this:
 `class=qubes.storage.xen.XenStorage`. Because R3.2 doesn't use Python
 `setup_hooks`, to actually use a short driver name for a custom storage driver,
 you have to patch `qubes-core-admin`. You can use the `class` config key
 instead, when your class is accessible by `import` in Python.
 
-A pool (in R3.2) is a configuration information which can be referenced when
+A pool (in R3.2) is configuration information which can be referenced when
 creating a new VM. Each pool is saved in `storage.conf`. It has a name, a
 storage driver and some driver specific configuration attached.
 
-When installed, the system has, as you can see from the content of
+When installed, the system has, as you can see from the contents of
 `/etc/qubes/storage.conf`, a pool named `default`. It uses the driver `xen`. The
 default pool is special in R3.2. It will add `dir_path=/var/lib/qubes`
 configuration value from `defaults[pool_config]`, if not overwritten.
 
 
 Currently the only supported driver out of the box is `xen`. The benefit of
-pools (besides that you can write an own storage driver e.g. for Btrfs) in R3.2
+pools (besides that you can write your own storage driver e.g. for Btrfs) in R3.2
 is that you can store your domains in multiple places.
 
 You can add a pool to `storage.conf` like this:
@@ -42,7 +42,7 @@ driver=xen
 dir_path=/opt/qubes-vm
 ```
 
-Now, when creating a new VM on the command-line, a you may pass the `-Pfoo`
+Now, when creating a new VM on the command-line, you may pass the `-Pfoo`
 argument to `qvm-create` to have the VM images stored in pool `foo`. See also
 `qvm-create --help`.