Introduction
============

There are two major components to this model: a canonical branch
and branches for each individual workshop. The canonical
branch serves several purposes: one, it is an incarnation of the
phrase, "the code is the documentation" and addresses the question,
"What is Software Carpentry?" If someone looks at the canonical
branch they will get a sense of the scope and depth of the SWC
project. Second, the canonical branch gives new instructors a starting
seed so they don't have to generate their lesson material from
scratch. The canonical branch will mostly be viewed by people
arriving from the web and will mostly be consumed by individuals
working alone. As such, the material in it should be constructed to
best serve those users. The individual workshop branches exist to
minimize the operational overhead of workshop instructors and to draw
a sharp logical boundary between different types of material that is
pitched at distinct audiences. Material in any workshop branch should be
constructed to best serve students attending that specific workshop.

Filesystem Structure
====================

The canonical branch and the workshop branch will have the same general
filesystem structure. Different modules will be organized into
different folders. For example, there may be a folder with material on
"python testing" or on "remote repos with git." The specific format of
the material in any of these folders as well as auxiliary files
(images, ipython notebooks, data) are decisions left up to the
developers/workshop instructors.

Canonical Branch Development Workflow
=====================================

The development model of the canonical branch will be the typical
DVCS github model: a contributor forks the repo into their own github
account, makes changes, then issues a pull request. SWC maintainers
look at the changes and merge them into the main repo when
appropriate.

Workshop Branch Development Workflow
====================================

The development workflow for a workshop is as follows: one of the
workshop instructors creates a new branch under the swcarpentry
github organization with a uniform name (YYYY-MM-location). The
repository is populated with material via copy-and-paste or by
merging in content from, say, a previous
workshop. Material in the repository is developed by instructors
commiting and pushing directly to the workshop branch without the fork/pull
request like in the canonical repo.

If the instructor wants to improve a general branch for their
workshop, they should create a feature branch version of the general
branch and commit their changes to the feature branch.  They should
submit a pull request to get their feature branch merged into the
general branch, but they can merge their feature branch into their
workshop branch and get on with their lives without waiting for the
pull request to get accepted.

After the workshop is over, they should tag the tip of their workshop
branch and delete the branch.  Git branches are basically tags that
move.  Once the workshop is done, there's no need for its tip commit
to change, so you might as well mark it with a tag.