Pull-Request/Issue Manager Responsibilities

The D Language Foundation employs two part-time pull-request managers thanks to the sponsorship of Symmetry Investments. One of them is intended to fill an administrative/managerial role, the other a more technically-oriented role. This document outlines their general responsibilities in managing the pull requests submitted to the D Programming Language Github organization repositories, and the issues submitted to issues.dlang.org.

The primary goal for the creation of these positions is to streamline the contribution process. We are grateful to the volunteers who have been doing the work of maintaining our Issue and PR queues over the past several years, but the loose nature of our process has been such that too many contributions grow stale (no one takes an interest, they become bottlenecked on one maintainer, etc). Contributors should have confidence that their submissions, be they bug reports or content contributions, will be reviewed and shepherded to a conclusion without languishing for long periods of time. With paid staff overseeing the process, we expect the process will become more efficient, and contributors will have a primary point of contact to assist with tracking and resolving their contributions.

The following list is divided into Administrative and Technical responsibilities. Some may overlap, and there may be loose boundaries between others. We trust the PR managers to establish their own approach to carrying out these responsibilities.

In the text below, APR refers the Administrative PR Manager Role, TPR refers to the Technical PR Manager Role.

Administrative Responsibilities

In order to effectively carry out his responsibilities, the APR needs to be aware of which core contributors are responsible for which areas and which community members to contact when necessary to resolve issues, and have an understanding of the general direction the language and ecosystem are going (i.e., for any given PR, the APR should be able to answer the question, "Do we do this?").

• Maintain the contribution guide - the contribution guide establishes best practices for submitting issues and pull requests. The APR should work with the TPR to evolve these details as needed and ensure the document is up to date.
• Triage issues and PRs - ensure that each issue report is properly prioritized and, where possible, assigned to someone who can resolve it; establish criteria to ensure that pull requests get as much time as they need for a proper review before being merged (e.g., trivial vs. complex, routine vs. controversial, etc); establish criteria to close issues/PRs; recognize when a pull request should first be incorporated as a DIP; etc.
• Keep track of progress - the APR should establish some means of keeping up to date on the status of every issue and PR in our system, and will be the primary point of contact for queries about the status of any issue or PR.
• Communicate with relevant parties - communication is vital to ensuring the efficient handling of issues and pull requests. Contributors will need to be sought out to resolve issues that are not picked up voluntarily; non-trivial pull requests will need to be reviewed by an appropriate core contributor/maintainer; contributors will need to be kept abreast of the status of their contributions when they cannot be resolved quickly; etc.

Technical Responsibilities

In order to effectively carry out the responsibilities of this role, the TPR needs a solid understanding of the architecture of our GitHub projects (i.e., for any given PR, the TPR should be able to answer the question, "Can we do this?").

• Ensure compliance with contribution guide - each issue and pull request should meet the guidelines established in the contribution guide. The TPR will work with contributors to ensure these guidelines are met (reduced test cases, proper commit message format, changelog entries, resolve merge conflicts, etc).
• Identify and resolve regressions - sometimes bugs are reported that are regressions, but not marked as such. The TPR should identify such issues, attempt to pinpoint the source of all reported regressions, and take steps to resolve them (e.g., contact the author/reviewer of the offending PR).
• Review trivial PRs - pull requests that need no specialized review should be reviewed and merged by the TPR.
• Fix trivial issues - the TPR is free to fix trivial issues and submit such fixes as pull requests, but must request review from a competent reviewer.