tweaks based on stoltz' input

content/admin-processes.md

@@ -7,7 +7,7 @@ The [process formation](/concurrency) is the array of processes that are used to
 * Running a console (also known as a [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) shell) to run arbitrary code or inspect the app's models against the live database.  Most languages provide a REPL by running the interpreter without any arguments (e.g. `python` or `erl`) or in some cases have a separate command (e.g. `irb` for Ruby, `rails console` for Rails).
 * Running one-time scripts committed into the app's repo (e.g. `php scripts/fix_bad_records.php`).
 
-One-off admin processes should be run in an identical environment as the regular [long-running processes](/processes) of the app.  The run against a [release](/build-release-run), using the same [code](/codebase) and [config](/config) as any process run against that release.
+One-off admin processes should be run in an identical environment as the regular [long-running processes](/processes) of the app.  They run against a [release](/build-release-run), using the same [code](/code) and [config](/config) as any process run against that release.
 
 The same [dependency isolation](/dependencies) techniques should be used on all process types.  For example, if the Ruby web process uses the command `bundle exec thin start`, then a database migration should use `bundle exec rake db:migrate`.  Likewise, a Python program using Virtualenv should use the vendored `bin/python` for running both the Tornado webserver and any `manage.py` admin processes.
 

content/build-release-run.md

@@ -4,8 +4,8 @@
 A [codebase](/codebase) is transformed into a (non-development) deploy through three stages:
 
 * The *build stage* is a transform which converts a code repo into an executable bundle known as a *build*.  Using a version of the code at a commit specified by the deployment process, the build stage fetches and vendors [dependencies](/dependencies) and compiles binaries and assets.
-* The *release stage* takes the build produced by the build stage and combines it with the deploy's current [config](/config).  The resulting *release* contains both the build and the config and is ready for immediate execution in the execution environment
-* The *run stage* (also sometimes referenced as "at runtime") runs the app, by launching some set of the app's [processes](/processes) against a selected release.
+* The *release stage* takes the build produced by the build stage and combines it with the deploy's current [config](/config).  The resulting *release* contains both the build and the config and is ready for immediate execution in the execution environment.
+* The *run stage* (also sometimes referenced as "at runtime") runs the app in the execution environment, by launching some set of the app's [processes](/processes) against a selected release.
 
 **The twelve-factor app uses strict separation between the build, release, and run stages.**  It is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage.  Config is accessible at runtime but not at build time, since config can change without triggering a build.
 

content/concurrency.md

@@ -11,4 +11,4 @@ This does not exclude individual processes from handling their own internal mult
 
 The process model truly shines when it comes time to scale out.  The [share-nothing, horizontally partitionable nature of twelve-factor app processes](/processes) means that adding more concurrency is a simple and reliable operation.  The array of process types and number of processes of each type is known as the *process formation*:
 
-Twelve-factor app proceses [should never daemonize](http://dustin.github.com/2010/02/28/running-processes.html) or write PID files.  It counts on the operating system's process manager (such as [Upstart](http://upstart.ubuntu.com/), a distributed process manager on a cloud platform, or a tool like [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) in development) to manage [output streams](/logs), respond to crashed processes, and handle user-initialed restarts and shutdowns.
+Twelve-factor app proceses [should never daemonize](http://dustin.github.com/2010/02/28/running-processes.html) or write PID files.  It counts on the operating system's process manager (such as [Upstart](http://upstart.ubuntu.com/), a distributed process manager on a cloud platform, or a tool like [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) in development) to manage [output streams](/logs), respond to crashed processes, and handle user-initiated restarts and shutdowns.

content/config.md

@@ -3,7 +3,7 @@
 
 An app's *config* is everything that is likely to vary between [deploys](/codebase) (staging, production, developer environments, etc).  This includes:
 
-* Resource handles to the database, Memcached, and other [backing services](#)
+* Resource handles to the database, Memcached, and other [backing services](/backing-services)
 * Credentials to external services such as Amazon S3 or Twitter
 * Per-deploy values such as the canonical hostname for the deploy
 

content/dev-prod-parity.md

@@ -1,5 +1,5 @@
 ## X. Dev/prod parity
-### Keep development and production and similar as possible
+### Keep development and production as similar as possible
 
 Historically, there is a substantial gap between development (a developer making live edits to a local [deploy](/codebase) of the app) and production (a running deploy of the app accessed by end users).  Gaps manifest in three areas:
 

content/logs.md

@@ -9,7 +9,7 @@ Logs are the [stream](http://adam.heroku.com/past/2011/4/1/logs_are_streams_not_
 
 In staging or production deploys, each process' stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival.  These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment.
 
-The event stream for an app can be routed to a file, or watched via realtime tail in a terminal.  Most significantly, the stream can be sent to into an log indexing and analysis system such as [Splunk](http://www.splunk.com/), or a general-purpose data warehousing system such as [Hadoop/Hive](http://hive.apache.org/).  These systems allow for great power and flexibility for introspecting an app's behavior over time, including:
+The event stream for an app can be routed to a file, or watched via realtime tail in a terminal.  Most significantly, the stream can be sent to a log indexing and analysis system such as [Splunk](http://www.splunk.com/), or a general-purpose data warehousing system such as [Hadoop/Hive](http://hive.apache.org/).  These systems allow for great power and flexibility for introspecting an app's behavior over time, including:
 
 * Finding specific events in the past.
 * Large-scale graphing of trends (such as requests per minute).

content/toc.md

@@ -29,7 +29,7 @@ The Twelve Factors
 ### Fast startup and graceful shutdown maximize robustness
 
 ## [X. Dev/prod parity](/dev-prod-parity)
-### Keep development and production and similar as possible
+### Keep development and production as similar as possible
 
 ## [XI. Logs](/logs)
 ### Logs are event streams

content/who.md

@@ -1,4 +1,4 @@
 Who should read this document?
 ==============================
 
-Any developer building applications run as a service.  Ops engineers who deploy or manage such applications.
+Any developer building applications which run as a service.  Ops engineers who deploy or manage such applications.