Merge pull request #6883 from Particular/nix-bohon-patch-3

Author: hazel-bohon

tutorials/nservicebus-step-by-step/2-sending-a-command/tutorial.md

@@ -28,10 +28,10 @@ snippet: Command
 
 By implementing this interface, we let NServiceBus know that the class is a command so that it can build up some metadata about the message type when the endpoint starts up. Any properties you create within the message constitutes the message data.
 
-The name of your command classes it is important, as they allow to infer the intent of the class without looking at its content. A command is an order to do something, so it should be named in the [imperative tense](https://en.wikipedia.org/wiki/Imperative_mood). 
+The name of your command class is important, as it allows others to infer the intent of the class without looking at its content. A command is an order to do something, so it should be named in the [imperative tense](https://en.wikipedia.org/wiki/Imperative_mood). 
 `PlaceOrder` and `ChargeCreditCard` are good names for commands, because they are phrased as a command and are very specific. We could expect that `PlaceOrder` will place an order and `ChargeCreditCard` will charge money on a credit card. `CustomerMessage`, on the other hand, is not a good example. It is not in the imperative, and it's vague. Ideally another person should know exactly what a command's purpose is just by reading its name.
 
-Command names should also convey business intent. `UpdateCustomerPropertyXYZ`, while more specific than `CustomerMessage` isn't a good name for an command because it's focused only on the data manipulation rather than the business meaning behind it. `MarkCustomerAsGold`, or something else that is domain oriented, is a better choice.
+Command names should also convey business intent. `UpdateCustomerPropertyXYZ`, while more specific than `CustomerMessage` isn't a good name for a command because it's focused only on the data manipulation rather than the business meaning behind it. `MarkCustomerAsGold`, or something else that is domain oriented, is a better choice.
 
 When sending a message, the endpoint's [serializer](/nservicebus/serialization/) will serialize the instance of the `DoSomething` class and add it to the contents of the outgoing message that goes to the queue. On the other end, the receiving endpoint will deserialize the message back to an instance of the message class so that it can be used by that endpoint.