Minor doc adjustments

Author: crbelaus

guides/Getting Started.md

@@ -1,14 +1,14 @@
 # Getting Started
 
-This guide is an introduction to the ErrorTracker, an Elixir based built-in error tracking solution. The ErrorTracker provides a basic and free error-tracking solution integrated in your own application. It is designed to be easy to install and easy to use so you can integrate it in your existing project with minimal changes. The only requirement is a relational database in which errors will be tracked.
+This guide is an introduction to ErrorTracker, an Elixir-based built-in error tracking solution. ErrorTracker provides a basic and free error-tracking solution integrated in your own application. It is designed to be easy to install and easy to use so you can integrate it in your existing project with minimal changes. The only requirement is a relational database in which errors will be tracked.
 
-In this guide we will learn how to install the ErrorTracker in an Elixir project so you can start reporting errors as soon as possible. We will also cover more advanced topics such as how to report custom errors and how to add extra context to reported errors.
+In this guide we will learn how to install ErrorTracker in an Elixir project so you can start reporting errors as soon as possible. We will also cover more advanced topics such as how to report custom errors and how to add extra context to reported errors.
 
-**This guide requires you to have setup Ecto with PostgreSQL beforehand.**
+**This guide requires you to have set up Ecto with PostgreSQL beforehand.**
 
 ## Installing the ErrorTracking as a dependency
 
-The first step add the ErrorTracker to your application is to declare the package as a dependency in your `mix.exs` file:
+The first step to add ErrorTracker to your application is to declare the package as a dependency in your `mix.exs` file:
 
 ```elixir
 # mix.exs
@@ -19,29 +19,29 @@ defp deps do
 end
 ```
 
-Once the ErrorTracker is declared as a dependency of your application, you can install it with the following command:
+Once ErrorTracker is declared as a dependency of your application, you can install it with the following command:
 
 ```bash
 mix deps.get
 ```
 
-## Configuring the ErrorTracker
+## Configuring ErrorTracker
 
-The ErrorTracker needs a few configuration options to work. This configuration should be added in your `config/config.exs` file:
+ErrorTracker needs a few configuration options to work. This configuration should be added to your `config/config.exs` file:
 
 ```elixir
 config :error_tracker,
   repo: MyApp.Repo,
   otp_app: :my_app
 ```
 
-The `:repo` option specifies the repository that will be used by the ErrorTracker. You can use your regular application repository, or a different one if you prefer to keep errors in a different database.
+The `:repo` option specifies the repository that will be used by ErrorTracker. You can use your regular application repository or a different one if you prefer to keep errors in a different database.
 
-The `:otp_app` option specifies your application name. When an error happens the ErrorTracker will use this information to understand which parts of the stacktrace belong to your application and which parts belong to third party dependencies. This allows you to filter in-app vs third-party frames when viewing errors.
+The `:otp_app` option specifies your application name. When an error occurs, ErrorTracker will use this information to understand which parts of the stack trace belong to your application and which parts belong to third-party dependencies. This allows you to filter in-app vs third-party frames when viewing errors.
 
 ## Setting up the database
 
-Since the ErrorTracker stores errors in the database you must create a database migration to add the required tables:
+Since ErrorTracker stores errors in the database you must create a database migration to add the required tables:
 
 ```
 mix ecto.gen.migration add_error_tracker
@@ -58,17 +58,17 @@ defmodule MyApp.Repo.Migrations.AddErrorTracker do
 end
 ```
 
-You can run the migration and perform the database changes with the following command:
+You can run the migration and apply the database changes with the following command:
 
 ```bash
 mix ecto.migrate
 ```
 
-For more information about how to handle migrations take a look at the `ErrorTracker.Migration` module docs.
+For more information about how to handle migrations, take a look at the `ErrorTracker.Migration` module docs.
 
 ## Automatic error tracking
 
-At this point, the ErrorTracker is ready to track errors. It will automatically start when your application boots and track errors that happen in your Phoenix controllers, Phoenix LiveViews and Oban jobs. The `ErrorTracker.Integrations.Phoenix` and `ErrorTracker.Integrations.Oban` provide detailed information about how this works.
+At this point, ErrorTracker is ready to track errors. It will automatically start when your application boots and track errors that occur in your Phoenix controllers, Phoenix LiveViews and Oban jobs. The `ErrorTracker.Integrations.Phoenix` and `ErrorTracker.Integrations.Oban` provide detailed information about how this works.
 
 If your application uses Plug but not Phoenix, you will need to add the relevant integration in your `Plug.Builder` or `Plug.Router` module.
 
@@ -81,7 +81,7 @@ defmodule MyApp.Router do
 end
 ```
 
-This is also required if you want to track errors that happen in your Phoenix endpoint, before the Phoenix router starts handling the request. Keep in mind that this won't be needed in most cases as endpoint errors are very infrequent.
+This is also required if you want to track errors that happen in your Phoenix endpoint, before the Phoenix router starts handling the request. Keep in mind that this won't be needed in most cases as endpoint errors are infrequent.
 
 ```elixir
 defmodule MyApp.Endpoint do
@@ -98,17 +98,17 @@ You can learn more about this in the `ErrorTracker.Integrations.Plug` module doc
 
 The default integrations include some additional context when tracking errors. You can take a look at the relevant integration modules to see what is being tracked out of the box.
 
-In certain cases you may want to include some additional information when tracking errors. For example it may be useful to track the user ID that was using the application when an error happened. Fortunately, the ErrorTracker allows you to enrich the default context with custom information.
+In certain cases, you may want to include some additional information when tracking errors. For example it may be useful to track the user ID that was using the application when an error happened. Fortunately, ErrorTracker allows you to enrich the default context with custom information.
 
-The `ErrorTracker.set_context/1` function stores the given context in the current process so any errors that happen in that process (for example a Phoenix request or an Oban job) will include this given context along with the default integration context.
+The `ErrorTracker.set_context/1` function stores the given context in the current process so any errors that occur in that process (for example, a Phoenix request or an Oban job) will include this given context along with the default integration context.
 
 ```elixir
 ErrorTracker.set_context(%{user_id: conn.assigns.current_user.id})
 ```
 
 ## Manual error tracking
 
-If you want to report custom errors that fall outside the default integrations scope you may use `ErrorTracker.report/2`. This allows you to report an exception by yourself:
+If you want to report custom errors that fall outside the default integration scope, you may use `ErrorTracker.report/2`. This allows you to report an exception yourself:
 
 ```elixir
 try do
@@ -123,6 +123,6 @@ You can also use `ErrorTracker.report/3` and set some custom context that will b
 
 ## Web UI
 
-The ErrorTracker also provides a dashboard built with Phoenix LiveView that can be used to see and manage the recorded errors.
+ErrorTracker also provides a dashboard built with Phoenix LiveView that can be used to see and manage the recorded errors.
 
-This is completely optional and you can find more information about it in the `ErrorTracker.Web` module documentation.
+This is completely optional, and you can find more information about it in the `ErrorTracker.Web` module documentation.

lib/error_tracker.ex

@@ -1,50 +1,50 @@
 defmodule ErrorTracker do
   @moduledoc """
-  En Elixir based built-in error tracking solution.
+  En Elixir-based built-in error tracking solution.
 
   The main objectives behind this project are:
 
-  * Provide a basic free error tracking solution: because tracking errors on
-  your application should be a requirement to almost any project, and helps to
+  * Provide a basic free error tracking solution: because tracking errors inm\
+  your application should be a requirement for almost any project, and helps to
   provide quality and maintenance to your project.
 
-  * Be easy to use: by providing plug and play integrations, documentation and a
+  * Be easy to use: by providing plug-and-play integrations, documentation and a
   simple UI to manage your errors.
 
   * Be as minimalistic as possible: you just need a database to store errors and
-  an Phoenix application if you want to inspect them via web. That's all.
+  a Phoenix application if you want to inspect them via web. That's all.
 
   ## Requirements
 
-  ErrorTracker requires Elixir 1.15+, Ecto 3.11+, Phoenix LiveView 0.19+ and PostgreSQL
+  ErrorTracker requires Elixir 1.15+, Ecto 3.11+, Phoenix LiveView 0.19+, and PostgreSQL.
 
   ## Integrations
 
   We currently include integrations for what we consider the basic stack of
-  an application: Phoenix, Plug and Oban.
+  an application: Phoenix, Plug, and Oban.
 
   However, we may continue working in adding support for more systems and
-  libraries in the future if there is enough interest by the community.
+  libraries in the future if there is enough interest from the community.
 
-  If you want to manually report an error you can use the `ErrorTracker.report/3` function.
+  If you want to manually report an error, you can use the `ErrorTracker.report/3` function.
 
   ## Context
 
-  Aside from the information abot each exception (kind, message, stacktrace...)
+  Aside from the information about each exception (kind, message, stack trace...)
   we also store contexts.
 
-  Contexts are arbitrary maps that allow you to store extra information of an
+  Contexts are arbitrary maps that allow you to store extra information about an
   exception to be able to reproduce it later.
 
-  Each integration includes a default context with the useful information they
-  can gather, but aside from that you can also add your own information. You can
-  do this in a per-process way or in a per-call way (or both).
+  Each integration includes a default context with useful information they
+  can gather, but aside from that, you can also add your own information. You can
+  do this in a per-process basis or in a per-call basis (or both).
 
   **Per process**
 
-  This allows you to set general context for the current process such as a Phoenix
-  request or an Oban job. For example you could include the following code in your
-  authentication Plug to automatically include the user ID on any error that is
+  This allows you to set a general context for the current process such as a Phoenix
+  request or an Oban job. For example, you could include the following code in your
+  authentication Plug to automatically include the user ID in any error that is
   tracked during the Phoenix request handling.
 
   ```elixir
@@ -53,9 +53,9 @@ defmodule ErrorTracker do
 
   **Per call**
 
-  As we had seen before you can use `ErrorTracker.report/3` to manually report an
+  As we had seen before, you can use `ErrorTracker.report/3` to manually report an
   error. The third parameter of this function is optional and allows you to include
-  extra context that will be tracked along with that error.
+  extra context that will be tracked along with the error.
   """
 
   @typedoc """
@@ -67,13 +67,13 @@ defmodule ErrorTracker do
   alias ErrorTracker.Repo
 
   @doc """
-  Report a exception to be stored.
+  Report an exception to be stored.
 
-  Aside from the exception, it is expected to receive the stacktrace and,
+  Aside from the exception, it is expected to receive the stack trace and,
   optionally, a context map which will be merged with the current process
   context.
 
-  Keep in mind that errors that happen in Phoenix controllers, Phoenix live views
+  Keep in mind that errors that occur in Phoenix controllers, Phoenix LiveViews
   and Oban jobs are automatically reported. You will need this function only if you
   want to report custom errors.
 
@@ -88,16 +88,16 @@ defmodule ErrorTracker do
 
   ## Exceptions
 
-  Exceptions passed can be in three different forms:
+  Exceptions can be passed in three different forms:
 
-  * An exception struct: the module of the exception is stored alongside with
+  * An exception struct: the module of the exception is stored along with
   the exception message.
 
-  * A `{kind, exception}` tuple in which the `exception` is an struct: it
+  * A `{kind, exception}` tuple in which the `exception` is a struct: it
   behaves the same as when passing just the exception struct.
 
-  * A `{kind, reason}` tuple: it stores the kind and the message itself casted
-  to strings, as it is useful for some errors like EXIT signals or custom error
+  * A `{kind, reason}` tuple: it stores the kind and the message itself cast
+  to strings, which is useful for some errors like EXIT signals or custom error
   messages.
   """
   def report(exception, stacktrace, given_context \\ %{}) do
@@ -151,13 +151,12 @@ defmodule ErrorTracker do
   end
 
   @doc """
-  Sets current process context.
+  Sets the current process context.
 
-  By default it will merge the current context with the new one received, taking
-  preference the new context's contents over the existsing ones if any key
-  matches.
+  The given context will be merged into the current process context. The given context
+  may override existing keys from the current process context.
 
-  ## Depth of the context
+  ## Context depth
 
   You can store context on more than one level of depth, but take into account
   that the merge operation is performed on the first level.

lib/error_tracker/migration.ex

@@ -1,10 +1,10 @@
 defmodule ErrorTracker.Migration do
   @moduledoc """
-  Create and modify the database tables for the ErrorTracker.
+  Create and modify the database tables for ErrorTracker.
 
   ## Usage
 
-  To use the ErrorTracker migrations in your application you will need to generate
+  To use ErrorTracker migrations in your application you will need to generate
   a regular `Ecto.Migration` that performs the relevant calls to `ErrorTracker.Migration`.
 
   ```bash
@@ -30,7 +30,7 @@ defmodule ErrorTracker.Migration do
   mix ecto.migrate
   ```
 
-  As new versions of the ErrorTracker are released you may need to run additional migrations.
+  As new versions of ErrorTracker are released you may need to run additional migrations.
   To do this you can follow the previous process and create a new migration:
 
   ```bash
@@ -73,7 +73,7 @@ defmodule ErrorTracker.Migration do
   ```
 
   This will automatically create the database schema for you. If the schema does already exist
-  the migration may fail when trying to recreate it. In such cases you can instruct the ErrorTracker
+  the migration may fail when trying to recreate it. In such cases you can instruct ErrorTracker
   not to create the schema again:
 
   ```elixir
@@ -85,7 +85,7 @@ defmodule ErrorTracker.Migration do
   end
   ```
 
-  If you are using a custom schema other than the default "public" you need to configure the
+  If you are using a custom schema other than the default "public" you need to configure
   ErrorTracker to use that schema:
 
   ```elixir

lib/error_tracker/schemas/error.ex

@@ -1,6 +1,6 @@
 defmodule ErrorTracker.Error do
   @moduledoc """
-  Schema to store an error or exception recorded by the ErrorTracker.
+  Schema to store an error or exception recorded by ErrorTracker.
 
   It stores a kind, reason and source code location to generate a unique
   fingerprint that can be used to avoid duplicates.

lib/error_tracker/web.ex

@@ -1,10 +1,10 @@
 defmodule ErrorTracker.Web do
   @moduledoc """
-  ErrorTracker includes a dashboard to view and inspect errors occurred on your
-  application and already stored on the database.
+  ErrorTracker includes a dashboard to view and inspect errors that occurred
+  on your application and are already stored in the database.
 
-  In order to use it, you need to add the following to your Phoenix's `
-  router.ex` file:
+  In order to use it, you need to add the following to your Phoenix's\
+  `router.ex` file:
 
   ```elixir
   defmodule YourAppWeb.Router do
@@ -17,14 +17,14 @@ defmodule ErrorTracker.Web do
   end
   ```
 
-  This will add the routes needed for the ErrorTracker dashboard to work.
+  This will add the routes needed for ErrorTracker's dashboard to work.
 
   ## Security considerations
 
   Errors may contain sensitive information, like IP addresses, users information
   or even passwords sent on forms!
 
-  Securing your dashboard is an important part of integrating `ErrorTracker` on
+  Securing your dashboard is an important part of integrating ErrorTracker on
   your project.
 
   In order to do so, we recommend implementing your own security mechanisms in

lib/error_tracker/web/router.ex

@@ -1,6 +1,6 @@
 defmodule ErrorTracker.Web.Router do
   @moduledoc """
-  Integration of the ErrorTracker UI into your application's router.
+  ErrorTracker UI integration into your application's router.
   """
 
   @doc """

mix.exs

@@ -50,7 +50,7 @@ defmodule ErrorTracker.MixProject do
   end
 
   def description do
-    "An Elixir based built-in error tracking solution"
+    "An Elixir-based built-in error tracking solution"
   end
 
   defp groups_for_modules do