diff --git a/docs/gameserver_spec.md b/docs/gameserver_spec.md
index 5802bc775f..e95db5453d 100644
--- a/docs/gameserver_spec.md
+++ b/docs/gameserver_spec.md
@@ -1,6 +1,6 @@
 # GameServer Specification
 
-Like any other Kubernetes ressources you describe a GameServer desired state via a specification written in YAML or JSON to the Kubernetes API. The Agones controller will then change the actual state to the desired state.
+Like any other Kubernetes resource you describe a GameServer's desired state via a specification written in YAML or JSON to the Kubernetes API. The Agones controller will then change the actual state to the desired state.
 
 A full GameServer specification is available below and in the [example folder](../examples/gameserver.yaml) for reference :
 
@@ -31,7 +31,7 @@ spec:
         imagePullPolicy: Always
 ```
 
-Since Agones defines a new [Custom Ressources Definition (CRD)](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) we can define a new ressource using the kind `GameServer` with the custom group `stable.agones.dev` and API version `v1alpha1`.
+Since Agones defines a new [Custom Resources Definition (CRD)](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) we can define a new resource using the kind `GameServer` with the custom group `stable.agones.dev` and API version `v1alpha1`.
 
 You can use the metadata field to target a specific [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) but also attach specific [annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) and [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to your ressource. This is a very common pattern in the Kubernetes ecosystem.
 
@@ -39,7 +39,7 @@ The `spec` field is the actual GameServer specification and it is composed as fo
 
 - `container` is the name of container running the GameServer in case you have more than one container defined in the [pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/). If you do,  this is a mandatory field. For instance this is useful if you want to run a sidecar to ship logs.
 - `portPolicy` has two options `dynamic` (default) the system allocates a free hostPort for the gameserver, for game clients to connect to. And `static`, user defines the hostPort that the game client will connect to. Then onus is on the user to ensure that the port is available. When static is the policy specified, `hostPort` is required to be populated.
-- `containerPort` the port that is being opened on the game server process, this is required field.
+- `containerPort` the port that is being opened on the game server process, this is a required field.
 - `protocol` the protocol being used. Defaults to UDP. TCP is the only other option.
 - `health` to track the overall healthy state of the GameServer, more information available in the [health check documentation](./health_checking.md).
-- `template` the [pod spec template](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#pod-v1-core) to run you GameServer containers, [see](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/#pod-templates) for more information.
\ No newline at end of file
+- `template` the [pod spec template](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#pod-v1-core) to run your GameServer containers, [see](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/#pod-templates) for more information.