SpongePowered · Inscrutable · Jul 23, 2017 · Jul 22, 2017 · Jul 22, 2017 · Jul 22, 2017
diff --git a/source/about/faq.rst b/source/about/faq.rst
@@ -110,8 +110,8 @@ It is even possible to use Sponge on the client-side, but for several tasks mods
 I'm a Bukkit Plugin Developer! Why Can't Sponge Use Bukkit's API?
 -----------------------------------------------------------------
 
-Bukkit’s API contains code licensed under the GPL. This is a large reason why Bukkit met its demise in September; by
-moving forward with a new API licensed under the MIT license, we can avoid some of the problems that fell upon Bukkit.
+Bukkit’s API contains code licensed under the GPL. This is a large reason why Bukkit met its demise in September 2014; 
+by moving forward with a new API licensed under the MIT license, we can avoid some of the problems that fell upon Bukkit.
 While this does not free us from Mojang’s control, as their code is proprietary, it is our belief that Mojang supports
 modding and will continue to do so.
 

diff --git a/source/contributing/implementation/datamanipulator.rst b/source/contributing/implementation/datamanipulator.rst
@@ -43,7 +43,7 @@ second is the interface implemented by the corresponding ``ImmutableDataManipula
 The Constructor
 ~~~~~~~~~~~~~~~
 
-In most cases while implementing an abstract Manipulator you want to have two constructors:
+In most cases while implementing an abstract ``DataManipulator`` you need to have two constructors:
 
 * One without arguments (no-args) which calls the second constructor with "default" values
 * The second constructor that takes all the values it supports.

diff --git a/source/contributing/index.rst b/source/contributing/index.rst
@@ -2,7 +2,7 @@
 Contributing to Sponge
 ======================
 
-This sections intends to show you ways to get involved with Sponge.
+This section shows you how to get involved with Sponge.
 
 What are the projects I can help with?
 ======================================

diff --git a/source/ore/publish.rst b/source/ore/publish.rst
@@ -93,7 +93,7 @@ command.
 
 .. note::
 
-    If you're using build manager such as Gradle or Maven, there is are plugins you can apply to your build script that
+    If you're using build manager such as Gradle or Maven, there are plugins you can apply to your build script that
     can sign built artifacts and automate this laborious process for you. For more information, please refer to
     `Gradle's documentation <https://docs.gradle.org/current/userguide/signing_plugin.html>`__ or
     `Maven's documentation <https://maven.apache.org/plugins/maven-gpg-plugin/>`__.

diff --git a/source/plugin/commands/arguments.rst b/source/plugin/commands/arguments.rst
@@ -145,7 +145,7 @@ Overview of the ``GenericArguments`` command elements
 |                            | is of invalid format and there are no more args.                                        |                               |
 +----------------------------+-----------------------------------------------------------------------------------------+-------------------------------+
 | ``firstParsing``           | Returns a command element that matches the first of the provided elements that parses   | inherited                     |
-|                            | (useful for command overloading, e.g. ``/settime <day|night|<number>>``).               |                               |
+|                            | (useful for command overloading, e.g. ``/settime <day|night|<number>``).                |                               |
 +----------------------------+-----------------------------------------------------------------------------------------+-------------------------------+
 | ``onlyOne``                | Restricts the given command element to only insert one value into the context at the    | inherited                     |
 |                            | provided key.                                                                           |                               |

diff --git a/source/plugin/event/causes.rst b/source/plugin/event/causes.rst
@@ -14,8 +14,8 @@ Event Causes
 
 Events are great for attaching additional logic to game actions, but they have the drawback of providing next to no
 context as to what has **caused** that event to occur. The :javadoc:`Cause` object allows providing and receiving
-additional contextual information about the event. This contextual information can then used to modify the behavior of
-your event listener.
+additional contextual information about the event. This contextual information can then be used to modify the behavior
+of your event listener.
 
 For example, a world protection plugin needs information on what player has caused a :javadoc:`ChangeBlockEvent` to
 occur before they can decide if the event should be cancelled or not. Rather than go with the traditional route of
@@ -30,7 +30,7 @@ Retrieving objects from a Cause
 
 Structurally, a ``Cause`` object contains a sequential list of objects. There are several methods of
 retrieving information from a Cause object which we will discuss here, for a more complete
-listing please see the javadocs **link**.
+listing please see the `Javadocs <https://jd.spongepowered.org>`_.
 
 .. note::
 

diff --git a/source/plugin/injection.rst b/source/plugin/injection.rst
@@ -24,7 +24,7 @@ Temporary List of Injected Types
 
 :javadoc:`ConfigDir` (annotation on Path or File)
   Used to inject the plugin's configuration directory:
-  ``./mods/`` OR ``./mods/<Plugin#id>/`` depending on :javadoc:`ConfigDir#sharedRoot()`
+  ``./config/`` OR ``./config/<Plugin#id>/`` depending on :javadoc:`ConfigDir#sharedRoot()`
 
 :javadoc:`ConfigurationLoader<CommentedConfigurationNode>`
   Must be annotated with ``@DefaultConfig``.
@@ -96,8 +96,8 @@ Game
 The ``Game`` object is the opening for many of the internal functions of the SpongeAPI, from the ``EventManager`` to the
 :javadoc:`Server` and even the Sync/Async :javadoc:`Scheduler`.
 
-It's entirely possible to receive the ``Game`` object from within most events, however it is commonly obtained through
-an injection.
+While it is entirely possible to retrieve the ``Game`` object through ``Sponge.getGame()``, it is commonly obtained
+through an injection.
 
 **Example - Field**
 
@@ -184,8 +184,8 @@ The recommended way to obtain your config file is through Guice, along with the
 DefaultConfig
 ~~~~~~~~~~~~~
 
-The way that ``@DefaultConfig`` works is very similar to ``@ConfigDir``. The biggest difference obviously being that
-``@DefaultConfig`` refers to a specific file, where ``@ConfigDir`` refers to a directory.
+The way that ``@DefaultConfig`` works is very similar to ``@ConfigDir``. The biggest difference is that
+``@DefaultConfig`` refers to a specific file, whereas ``@ConfigDir`` refers to a directory.
 
 .. tip::
 

diff --git a/source/plugin/permissions.rst b/source/plugin/permissions.rst
@@ -37,38 +37,38 @@ Allowed characters are:
 Inheritance
 ~~~~~~~~~~~
 
-If a user has the permission ``myPlugin.commands`` then they automatically have all sub permissions such as
-``myPlugin.commands.teleport`` unless the permissions are explicitly removed.
+If a user has the permission ``myplugin.commands`` then they automatically have all sub permissions such as
+``myplugin.commands.teleport`` unless the permissions are explicitly removed.
 
 .. note::
 
-    There is no such thing as a ``myPlugin.commands.*`` wildcard permission.
-    Use ``myPlugin.commands`` for that.
+    There is no such thing as a ``myplugin.commands.*`` wildcard permission.
+    Use ``myplugin.commands`` for that.
 
 Structure-Example
 ~~~~~~~~~~~~~~~~~
 
 The following example show one possible way of structuring permissions, but following this structure is not required at
 all.
 
-* ``myPlugin``
+* ``myplugin``
     * Grants **full** access to all plugin's permissions.
 
-* ``myPlugin.commands``
+* ``myplugin.commands``
     * Grants **full** access to all plugin's commands.
 
-* ``myPlugin.commands.teleport.execute``
+* ``myplugin.commands.teleport.execute``
     * Only grants the user the permission to execute the command. Without this permission he is not able to execute the
       command even if he has other `teleport` permissions.
       (With this permission alone the user would only be able to teleport himself to others in his current world.)
 
-* ``myPlugin.commands.teleport.all``
+* ``myplugin.commands.teleport.all``
     * Only grants the user the permission to teleport all players at once.
 
-* ``myPlugin.commands.teleport.worlds``
+* ``myplugin.commands.teleport.worlds``
     * Only grants the user the permission to teleport to all worlds.
 
-* ``myPlugin.commands.teleport.worlds.mynetherworld``
+* ``myplugin.commands.teleport.worlds.mynetherworld``
     * Only grants the user the permission to teleport to *mynetherworld*.
 
 PermissionDescription
@@ -99,10 +99,10 @@ Usage-Example
     import org.spongepowered.api.text.Text;
     import java.util.Optional;
 
-    Optional<Builder> optBuilder = permissionService.newDescriptionBuilder(myPlugin);
+    Optional<Builder> optBuilder = permissionService.newDescriptionBuilder(myplugin);
     if (optBuilder.isPresent()) {
         Builder builder = optBuilder.get();
-        builder.id("myPlugin.commands.teleport.execute")
+        builder.id("myplugin.commands.teleport.execute")
                .description(Text.of("Allows the user to execute the teleport command."))
                .assign(PermissionDescription.ROLE_STAFF, true)
                .register();
@@ -113,7 +113,7 @@ Simple-Result
 
 .. code-block:: text
 
-    myPlugin.commands.teleport.execute
+    myplugin.commands.teleport.execute
 
     Description: Allows the user to execute the teleport command.
     Role: user
@@ -124,16 +124,16 @@ Template-Result
 
 .. code-block:: text
 
-    myPlugin.commands.teleport.worlds.<World>
+    myplugin.commands.teleport.worlds.<World>
 
     Description: Allows the user to teleport to the world <World>.
     Role: staff
     Owner: MyPlugin v1.2.3
 
 .. tip::
 
-    You might skip writing descriptions for some parent permission groups such as ``myPlugin.commands.teleport.worlds``
-    or ``myPlugin.commands`` as their meaning can be derived from the permission structure and the defined children
+    You might skip writing descriptions for some parent permission groups such as ``myplugin.commands.teleport.worlds``
+    or ``myplugin.commands`` as their meaning can be derived from the permission structure and the defined children
     alone.
 
 Subject
@@ -160,9 +160,9 @@ The following example could be used to check whether the Player is allowed to ex
     import org.spongepowered.api.world.World;
 
     public boolean canTeleport(Player subject, World targetWorld) {
-        return subject.hasPermission("myPlugin.command.teleport.execute") 
+        return subject.hasPermission("myplugin.command.teleport.execute") 
                 && (subject.getWorld() == targetWorld
-                        || subject.hasPermission("myPlugin.command.teleport." + targetWorld.getName()));
+                        || subject.hasPermission("myplugin.command.teleport." + targetWorld.getName()));
     }
 
 Inheritance
@@ -307,9 +307,9 @@ Your ``ContextCalculator`` may look like this:
 
     public class ExampleCalculator implements ContextCalculator<Subject> {
 
-        private static final Context IN_ANY_ARENA = new Context("myArenaPlugin-inAnyArena", "true");
-        private static final Context NOT_ANY_ARENA = new Context("myArenaPlugin-inAnyArena", "false");
-        private static final String ARENA_KEY = "myArenaPlugin-arena";
+        private static final Context IN_ANY_ARENA = new Context("myarenaplugin-inAnyArena", "true");
+        private static final Context NOT_ANY_ARENA = new Context("myarenaplugin-inAnyArena", "false");
+        private static final String ARENA_KEY = "myarenaplugin-arena";
 
         private final Map<UUID, String> playerArenas = new HashMap<>();
 

diff --git a/source/plugin/scheduler.rst b/source/plugin/scheduler.rst
@@ -93,7 +93,7 @@ Using the ``Task.Builder``, you can specify other, optional properties, as descr
 +-----------------+-------------------------+--------------------------------------------------------------------------+
 | name            | name(String name)       | The name of the task. By default, the name of the task will be           |
 |                 |                         | PLUGIN_ID "-" ( "A-" | "S-" ) SERIAL_ID. For example, a default task name|
-|                 |                         | could look like "FooPlugin-A-12". No two active tasks will have the same |
+|                 |                         | could look like "fooplugin-A-12". No two active tasks will have the same |
 |                 |                         | serial ID for the same synchronization type. If a task name is specified,|
 |                 |                         | it should be descriptive and aid users in debugging your plugin.         |
 +-----------------+-------------------------+--------------------------------------------------------------------------+

diff --git a/source/server/getting-started/configuration/server-properties.rst b/source/server/getting-started/configuration/server-properties.rst
@@ -381,11 +381,11 @@ Credit goes to the editors at the `Minecraft Wiki <http://minecraft.gamepedia.co
 |                               |             |             | as those for real-life friends or strangers carefully      |
 |                               |             |             | selected via an application process, for example.          |
 |                               |             |             |                                                            |
-|                               |             |             |  **false** - No white list is used.                        |
+|                               |             |             |  **false** - No whitelist is used.                         |
 |                               |             |             |                                                            |
 |                               |             |             |  **true** - The file ``whitelist.json`` is used to         |
-|                               |             |             |  generate the white list.                                  |
+|                               |             |             |  generate the whitelist.                                   |
 |                               |             |             |                                                            |
-|                               |             |             | **Note:** *Ops are automatically white listed, and there*  |
+|                               |             |             | **Note:** *Ops are automatically whitelisted, and there*   |
 |                               |             |             | *is no need to add them to the whitelist.*                 |
 +-------------------------------+-------------+-------------+------------------------------------------------------------+