@@ -17,34 +17,25 @@ This episode describes the processes used to maintain our lessons.
## Maintainers
Each Software or Data Carpentry lesson has one or two maintainers,
Each Carpentry lesson has multiple 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.
and the latter from the Carpentry Executive Council and Curricular Advisory Committees.
The process for selecting and onboarding a new maintainer is:
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 or Data 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.
* Opportunity for new Maintainers is announced via blog post, mailing list, and Twitter with link to application form.
* Applications accumulate.
* Applications are reviewed (e.g. by existing Maintainers for that lesson).
* The new Maintainer(s) are informed, and other applicants are thanked via email.
* To onboard the new Maintainer(s):
* Ask new Maintainer(s) to add themselves to the [Maintainers' email list](http://lists.software-carpentry.org/listinfo/maintainers).
* Invite new Maintainer(s) to join [Maintainer Onboarding Google Group](https://groups.google.com/a/carpentries.org/forum/#!forum/maintainer-onboarding).
* Invite new Maintainer(s) to join [Maintainer meetings](http://pad.software-carpentry.org/maintainers).
* New cohort of Maintainer(s) complete [Maintainer Onboarding](https://carpentries.github.io/maintainer-onboarding/).
* Request write access for new Maintainer(s) to the appropriate repos from the Carpentry Executive Director.
## Release Process and Schedule
@@ -53,13 +44,13 @@ 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,
the *lesson Maintainer(s)* 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.
3. A *Release Maintainer* generates HTML pages for that release and adds 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
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`
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.
