Cumulative Maintainer Responsibilities

Over the course of the maintenance pilot we have been adding additional responsibilities bit-by-bit. This is the cumulative view of what those responsibilities are and how we are doing against our commitments. This version is a self-assessment so each maintainer should complete this for the repositories under maintenance.

Responsibilities

1. Create a useful catalog-info.yaml file.

2. Bring the README in line with our standards.

3. Requirements bot is installed.

4. GitHub Notifications are enabled
   Maintainers must update their GitHub notification settings so that they are getting PR messages and can be tagged

5. GitHub Issues are enabled

6. The maintainers are reachable in Discourse

   1. For individual maintainers: Maintainers should have accounts and should receive notifications if they are directly mentioned in regards to maintainer responsibilities.

   2. For team maintainers: This workflow is still evolving. Some examples:

      1. Aperture Repo Maintainership Process

      2. 2U>T&L Repo Maintainership Process

7. Incoming Pull Requests from community members should be triaged within a week.
   The goal is to reduce lead-time to finalize contributions from folks who do not have direct merge rights to a repository. Ideally finalize is to merge the change, but it can also be rejecting it. The contributor should know quickly and definitively whether the change was merged, rejected or requires changes. This SLA is currently measuring time to triage the PR. Triaging means acknowledging the contribution and giving the author clarity about what happens next: I’ll review this tomorrow, it is in our next sprint starting Monday, etc. And, crucially fulfilling the expectations you have set about what happens next.
   
   Incoming pull requests are visible here. Teams typically are on the hook for items that are in the “Ready for Review” state.
   
   Community Project Managers – @Michelle Philbrick and @Tim Krones – are continuously watching, curating, cajoling, unblocking these pull requests to keep their statuses accurate.

8. Author updates should be responded to within a week.
   This requirement is really an extension of the above, but focused on making sure reviews get to done when authors are responsive. Ideally when authors are responsive, we are keeping reviews active and not pushing across sprint boundaries for every interaction.

9. Security fixes should be applied weekly
   The edx-requirements bot will create pull requests in your repository to update any out of date requirements. The bot, however, doesn’t specifically flag which updates are security fixes. You may get this information by enabling Dependabot from your repositories settings. You can configure it to send alerts, but not create pull requests. Dependabot alerts will be visible from the “Security” tab in your repositories.

Current Scorecard