diff --git a/_episodes/04-mechanics.md b/_episodes/04-mechanics.md
new file mode 100644
index 0000000000000000000000000000000000000000..de1227ef49db716bde7d18615749e605e3593212
--- /dev/null
+++ b/_episodes/04-mechanics.md
@@ -0,0 +1,56 @@
+---
+title: "Mechanics"
+teaching: 5
+exercises: 0
+questions:
+- "What do lesson maintainers do?"
+objectives:
+- "FIXME"
+keypoints:
+- "FIXME"
+---
+This episode describes the processes used to maintain our lessons.
+
+## Maintainers
+
+Each Software or Data Carpentry lesson has one or two maintainers,
+who are responsible for making sure issues and change requests are looked at,
+and who have final say over what is included in the lesson.
+Together,
+they also decide on changes to the lesson templates,
+release procedure,
+and other mechanical aspects of lesson production.
+They are *not* responsible for writing lesson content or deciding what lessons ought to exist:
+the former comes from the community,
+and the latter from the Executive Directors and Steering Committees of Software and Data Carpentry.
+
+The process for selecting and onboarding a new maintainer is:
+
+*   Outgoing maintainer emails the discussion list to announce the opportunity
+    *    Application information includes name, github username, statement of intent.
+    *    Deadline for applications, projected timeline for selection.
+    *    Name/email of contact for application process (typically outgoing maintainer).
+*   Applications accumulate over a week or two.
+*   Outgoing maintainer and their co-maintainer review applications and choose new maintainer. 
+*   The new maintainer is informed, and other applicants are thanked via email. 
+*   To onboard the new maintainer:
+    *    Add new maintainer to the maintainers' list.
+    *    Email the maintainers to announce the change. 
+    *    Request push/merge access for new maintainer from the Software Carpentry executive director.  
+    *    Write a blog post introducing new maintainer.  
+    *    Optional: call between outgoing/incoming maintainer to discuss state of the repository, transition strategy, etc. 
+
+## Release Process and Schedule
+
+We have decided to use a **6-month release cycle** for releases, which
+will be named by the year and month they happen, e.g., `2016.05`.
+
+1. Each lesson lives in the `gh-pages` branch of its own repository.
+2. When a release has to be made,
+    the *lesson maintainer* (or maintainers) create a branch named after the release, e.g., `2016.05`.
+3. A *release maintainer* generates HTML pages for that release and add them to the branch.
+4. If there isn't already a directory for that release in the `swc-release` repository,
+   the release maintainer creates one
+   and adds an `index.html` page to it.
+5. The release maintainer adds a submodule to the release directory of `swc-release`
+   that points to the newly-created release branch of the lesson.
diff --git a/_episodes/04-divs.md b/_episodes/05-divs.md
similarity index 100%
rename from _episodes/04-divs.md
rename to _episodes/05-divs.md
diff --git a/setup.md b/setup.md
index 770e3b2ad84d1d3fcbfb1421a4d4b2aa9b832faa..28d432ec6528008751593237d6c5130085023236 100644
--- a/setup.md
+++ b/setup.md
@@ -3,6 +3,11 @@ layout: page
 title: Setup
 permalink: /setup/
 ---
-The setup instructions go here,
-divided into sections by platform
-(Windows, Mac OS X, and Linux).
+1. Installation instructions for core lessons are included in the [workshop template's home page][template],
+   so that they are all in one place.
+   The `setup.md` files of core lessons link to the appropriate sections of the [workshop template page][template].
+
+2. Other lessons' `setup.md` include full installation instructions organized by OS
+   (following the model of the workshop template home page).
+
+[template]: {{ site.workshop_repo }}