Index: user-guide/deploy.conf
===================================================================
--- user-guide/deploy.conf	(revision 1150180)
+++ user-guide/deploy.conf	(working copy)
@@ -1,7 +1,7 @@
 h1. Deploy Cellar
 
 This chapter describes how to deploy and start Cellar into a running Apache Karaf instance. This chapter
-assumes that you already know the Apache Karaf basics, especially the notion of feature and shell usage.
+assumes that you already know Apache Karaf basics, especially the notion of features and shell usage.
 
 h2. Registering Cellar features
 
Index: user-guide/groups.conf
===================================================================
--- user-guide/groups.conf	(revision 1150180)
+++ user-guide/groups.conf	(working copy)
@@ -1,7 +1,7 @@
 h1. Cellar groups
 
 You can define groups in Cellar. A group allows you to define specific nodes and resources that are to be
-working together. This permits some nodes (those outside the group) not to need to sync with changes of
+working together. This permits some nodes (those outside the group) not to need to be sync'ed with changes of
 a node within a group.
 
 By default, the Cellar nodes go into the default group:
@@ -57,7 +57,7 @@
 org.apache.karaf.shell  
 {code}
 
-You can use the cluster:config-proplist, config-propset commands to list, add and edit the configuration.
+You can use the cluster:config-proplist and config-propset commands to list, add and edit the configuration.
 
 For instance, in the test group, we don't have any configuration:
 
@@ -87,7 +87,7 @@
 
 h2. Group members
 
-You can define a node member of one of more group:
+You can declare a node a member of one of more groups:
 
 {code}
 karaf@root> cluster:group-join test node1.local:5701
@@ -97,10 +97,10 @@
   node1:5701 test
 {code}
 
-The node could be local or remote.
+The node can be local or remote.
 
 Now, the members of a given group will inherit of all configuration defined in the group. This means that
-node1 now knows the tstcfg configuration because it's test group member:
+node1 now knows the tstcfg configuration because it's a member of the test group:
 
 {code}
 karaf@root> config:edit tstcfg
@@ -183,7 +183,7 @@
 eventadmin                                     3.0.0-SNAPSHOT true 
 {code}
 
-The eventadmin feature has been installed on the test group members:
+Below, we see that the eventadmin feature has been installed on this member of the test group:
 
 {code}
 karaf@root> features:list|grep -i event
Index: user-guide/installation.conf
===================================================================
--- user-guide/installation.conf	(revision 1150180)
+++ user-guide/installation.conf	(working copy)
@@ -17,12 +17,14 @@
 * 100MB of free disk space for the Apache Karaf Cellar x.y source distributions or SVN checkout, the Maven build and the dependencies that Maven downloads.
 
 *Environment:*
-* Java SE Developement Kit 1.6.x or greater ([http://www.oracle.com/technetwork/java/javase/]).
+* Java SE Development Kit 1.6.x or greater ([http://www.oracle.com/technetwork/java/javase/]).
 * Apache Maven 3.0.3 ([http://maven.apache.org/download.html]).
 
+*Note:* Karaf Cellar requires Java 6 to compile, build and run.
+
 h3. Building on Windows
 
-This procedure explains how to download and install the source distribution on a Windows system. *NOTE:* Karaf Cellar requires Java 6 to compile, build and run.
+This procedure explains how to download and install the source distribution on a Windows system.
 # From a browser, navigate to [http://karaf.apache.org/sub-projects/cellar/download.html].
 # Select the desired distribution.
 For a source distribution, the filename will be similar to: {{apache-karaf-cellar-x.y-src.zip}}.
@@ -40,7 +42,7 @@
 
 h3. Building on Unix
 
-This procude explains how to download and install the source distribution on an Unix system. *Note:* Karaf Cellar requires Java 6 to compile, build and run.
+This procedure explains how to download and install the source distribution on an Unix system. 
 # From a browser, navigate to [http://karaf.apache.org/sub-projects/cellar/download.html].
 # Select the desired distribution.
 For a source distribution, the filename will be similar to: {{apache-karaf-cellar-x.y-src.tar.gz}}.
Index: overview.conf
===================================================================
--- overview.conf	(revision 1150180)
+++ overview.conf	(working copy)
@@ -1,13 +1,13 @@
 h1. Karaf Cellar Overview
 
-Apache Karaf Cellar is a Apache Karaf sub-project which provide cluster support in Karaf.
+Apache Karaf Cellar is a Apache Karaf sub-project which provides clustering support between multiple Karaf instances.
 
-Cellar allows you to manage a cluster of several Karaf instances, providing synchronization between instances.
+Here is a short list of Cellar features:
 
-Here is a short list of features:
+* *Discovery*: when you install Cellar into a Karaf instance, it automatically tries to join the cluster of other Cellar-running Karaf instances it discovers. There is no configuration required to join the cluster, the discovery is made behind the scenes, with multicast or unicast used for discovery.
+* *Cluster Group*: a Karaf node can be part of one or more cluster groups. In Cellar, you can define cluster groups per your requirements. Resources will be sync'ed between members of the same group.
+* *Distributed Configuration Admin*: Cellar distributes configuration data, both of Cellar-specific and Karaf etc/*.cfg configuration files. The distribution is event driven and filtered by group. You can tune the configuration replication using blacklists/whitelists on the configuration ID (PID).
+* *Distributed Features Service*: Cellar distribututes features and feature repository information, also an event-driven process.
+* *Provisioning*: Cellar provides shell commands for basic provisioning. It can also use an OBR backend or another provisioning tool such as Apache ACE.
 
-* *Discovery*: when you install Cellar into a Karaf instance, it automatically tries to discover other Cellar instances and join the cluster. There is no configuration required to join the cluster, the discovery is made behind the scene. You can use multicast or unicast for discovery.
-* *Cluster Group*: a Karaf node could be part of one or more cluster group. In Cellar, you can define cluster group depending of your requirements. The resources will be sync between members of the same group.
-* *Distributed Configuration Admin*: Cellar distributes the configuration data. The distribution is event driven and filtered by group. You can tune the configuration replication using blacklist/whitelist on the configuration ID (PID).
-* *Distributed Features Service*: Cellar distribututes the features/repos info. It's also event-driven.
-* *Provisioning*: Cellar provides shell commands for basic provisioning. It can also use an OBR backend or another provisioning tool such as Apache ACE.
+
Index: architecture-guide/hazelcast.conf
===================================================================
--- architecture-guide/hazelcast.conf	(revision 1150180)
+++ architecture-guide/hazelcast.conf	(working copy)
@@ -1,4 +1,4 @@
-h1. The role of Hazelcast
+h1. The role of Hazelcast 
 
 The idea behind the clustering engine is that for each unit that we want to replicate, we create an event,
 broadcast the event to the cluster and hold the unit state to a shared resource, so that the rest of the
@@ -26,3 +26,5 @@
 
 In other words, Hazelcast allows us to setup a cluster with zero configuration and no dependency to external
 systems such as a database or a shared file system.
+
+See the Hazelcast documentation at http://www.hazelcast.com/documentation.jsp for more information.
Index: architecture-guide/overview.conf
===================================================================
--- architecture-guide/overview.conf	(revision 1150180)
+++ architecture-guide/overview.conf	(working copy)
@@ -8,8 +8,8 @@
 
 Each group comes with a configuration, which defines which events are to be broadcasted and which are
 not. Whenever a local change occurs to a node, the node will read the setup information of all the
-groups that it belongs to and broadcasts the event to the groups that are whitelisted the specific event.
+groups that it belongs to and broadcasts the event to the groups that are whitelisted to the specific event.
 
-The broadcast operation happens via the distributed topic provided by the group. For the groups
+The broadcast operation happens via a distributed topic provided by the group. For the groups
 that the broadcast reaches, the distributed configuration data will be updated so that nodes
Index: architecture-guide/design.conf
===================================================================
--- architecture-guide/design.conf	(revision 1150180)
+++ architecture-guide/design.conf	(working copy)
@@ -4,8 +4,8 @@
 
 * *OSGi Listener* An interface which implements a listener for specific OSGi events (e.g. ConfigurationListener).
 * *Event* The object that contains all the required information required to describe the event (e.g. PID changed).
-* *Event Topic* The distributed topic use to broadcast events. It is common for all event types.
-* *Shared Map* The distributed collection the serves as shared resource. We use one per event type.
+* *Event Topic* The distributed topic used to broadcast events. It is common for all event types.
+* *Shared Map* The distributed collection that serves as a shared resource. We use one per event type.
 * *Event Handler* The processor which processes remote events received through the topic.
 * *Event Dispatcher* The unit which decides which event should be processed by which event handlers.
 * *Command* A special type of event that is linked to a list of events that represent the outcome of the command.
@@ -13,9 +13,9 @@
 
 !/images/event_flow.jpg!
 
-The OSGi specification uses Events and Listener paradigm in many situations (e.g. ConfigurationChangeEvent
-and ConfigurationListener). By implementing such Listener and expose it as an OSGi service to the Service
-Registry, we can be sure that we are "listening" for the interesting events.
+The OSGi specification uses the Events and Listener paradigm in many situations (e.g. ConfigurationChangeEvent
+and ConfigurationListener). By implementing such a Listener and exposing it as an OSGi service to the Service
+Registry, we can be sure that we are "listening" for the events that we are interested in.
 
 When the listener is notified of an event, it forwards the Event object to a Hazelcazst distributed topic. To
 keep things as simple as possible, we keep a single topic for all event types. Each node has a listener
Index: architecture-guide/supported_events.conf
===================================================================
--- architecture-guide/supported_events.conf	(revision 1150180)
+++ architecture-guide/supported_events.conf	(working copy)
@@ -14,6 +14,6 @@
 memory of the default group and will also be broadcasted to all other default group members using the topic.
 
 This happens for all PIDs but not for org.apache.karaf.cellar.node which is marked as blacklisted
-and will never be written or read from the distributed memory, nor will broadcasted via the topic.
+and will never be written or read from the distributed memory, nor will be broadcasted via the topic.
 
 The user can add/remove any PID he wishes to the whitelist/blacklist.