   The `PartitionSupervisor` requires a name as an atom to be given on start,
   as it uses an ETS table to keep all of the partitions. Under the hood,
   the `PartitionSupervisor` generates a child spec for each partition and
-  then act as a regular supervisor. The id of each child spec is the
+  then act as a regular supervisor. The ID of each child spec is the
   partition number.
 
   For routing, two strategies are used. If `key` is an integer, it is routed
-  using `rem(abs(key), partitions)`. Otherwise it uses `:erlang.phash2(key, partitions)`.
-  The particular routing may change in the future, and therefore cannot
+  using `rem(abs(key), partitions)` where `partitions` is the number of
+  partitions. Otherwise it uses `:erlang.phash2(key, partitions)`.
+  The particular routing may change in the future, and therefore must
   be relied on. If you want to retrieve a particular PID for a certain key,
   you can use `GenServer.whereis({:via, PartitionSupervisor, {name, key}})`.
   """

  The `DynamicSupervisor` is a single process responsible for starting
  other processes. In some applications, the `DynamicSupervisor` may
  become a bottleneck. To address this, you can start multiple instances
  of the `DynamicSupervisor` and then pick a "random" instance to start
  the child on.

  Instead of:

      children = [
        {DynamicSupervisor, name: MyApp.DynamicSupervisor}


  ## Options

    * `:name` - an atom representing the name of the partition supervisor
      (see `t:name/0`).

    * `:partitions` - a positive integer with the number of partitions.
      Defaults to `System.schedulers_online()` (typically the number of cores).
