Maintaining Lessons - Community Perspectives

This post originally appeared on the Software Carpentry website.

Our September community call on lesson maintenance brought up many good ideas around the lesson maintenance process for Software and Data Carpentry lessons. If you weren’t able to make the call, below is a summary of our discussion and potential avenues for growth.

Our discussion focused around two major questions: what do the lesson maintainers do, and what are some of the reasons to be a lesson maintainer?

What do lesson maintainers do?

Managing Issues and Pull Requests (PRs)

A big piece of a lesson maintainer’s job is to respond to the issues and pull requests that are submitted to their lesson repository. Depending on the extent of the suggested change, or the number of submissions, this process can be brief or time-consuming per week.

There have been more and more contributions over the past few months as future Software and Data Carpentry instructors are required to submit a change or suggestion as part of their checkout process.

Room to grow:

• General guidelines for the maintainers; how quickly to respond to PRs, when to close them, etc.
• In instructor training, emphasize the equal importance of review, not necessarily submitting new issues/PRs, as lesson contribution
• Coordinate with maintainers when there may be “bursts” of work (lots of instructor training, Bug BBQs)

Curriculum Decisions and Feedback

An extension of managing a lesson’s changes (via issues and pull requests) is making larger decisions about the lesson as a whole. More significant issues can come up as the lesson grows (for example: in an R lesson, whether to emphasize tidyverse or base R), requiring a decision from the maintainers about which direction to go.

In addition to these larger changes, there isn’t always a good way to provide centralized feedback from the lessons after they’re taught. We have discussion sessions, but that information isn’t always communicated back to the maintainers.

Room to grow:

• Possibly provide some kind of “advisory” structure to the individual lesson maintainers for more big-picture decisions; currently being tested by the Data Carpentry genomics maintainers
• Communicate clear channels for providing feedback (both good and bad!) about the lessons.
• Have a process for working on larger changes (possibly separating the lessons into a “stable” and “development” release, one version of this described here).

What are the benefits of being a maintainer?

In our discussion, several benefits for being a maintainer arose:

• Professional credit:
  • We publish the lessons at least once a year and these can be listed as publications on a CV. Maintainers are equivalent to editors of a volume.
  • Maintainership can be an item on a job or tenure application.
• Improving your git skills, especially for managing a collaborative project. These are skills that can translate to other areas, including software development and teaching.
• Interacting with a wide variety of community members (via issues and pull requests)
• Being able to support something you believe in (teaching data or computing skills) by maintaining the lesson material.
• Seeing different perspectives on a particular lesson; understanding why it is the way it is.

Room to grow:

• Address some of the previous challenges in order to make maintaining lessons more accessible.
• Create some standard descriptive wording for use in applications for jobs, tenure, and grants that maintainers can use to highlight their contributions.
• Publicize our lesson publication information more widely.

We hope to address some of the growth areas in the next few months; contact Erin Becker or Christina Koch if you have questions or feedback about the future of lesson maintenance.