|
| 1 | +Ddoc |
| 2 | + |
| 3 | +$(D_S $(TITLE)) |
| 4 | + |
| 5 | +$(P The D Language Foundation employs two part-time pull-request managers thanks |
| 6 | +to the sponsorship of Symmetry Investments. One of them is intended to fill an |
| 7 | +administrative/managerial role, the other a more technically-oriented role. This |
| 8 | +document outlines their general responsibilities in managing the pull requests |
| 9 | +submitted to $(LINK2 https://github.com/dlang, the D Programming Language Github |
| 10 | +organization repositories), and the issues submitted to $(LINK2 |
| 11 | +https://issues.dlang.org/, issues.dlang.org).) |
| 12 | + |
| 13 | +$(P The primary goal for the creation of these positions is to streamline the |
| 14 | +contribution process. We are grateful to the volunteers who have been doing the |
| 15 | +work of maintaining our Issue and PR queues over the past several years, but the |
| 16 | +loose nature of our process has been such that too many contributions grow stale |
| 17 | +(no one takes an interest, they become bottlenecked on one maintainer, etc). |
| 18 | +Contributors should have confidence that their submissions, be they bug reports |
| 19 | +or content contributions, will be reviewed and shepherded to a conclusion |
| 20 | +without languishing for long periods of time. With paid staff overseeing the |
| 21 | +process, we expect the process will become more efficient, and contributors will |
| 22 | +have a primary point of contact to assist with tracking and resolving their |
| 23 | +contributions.) |
| 24 | + |
| 25 | +$(P The following list is divided into Administrative and Technical |
| 26 | +responsibilities. Some may overlap, and there may be loose boundaries between |
| 27 | +others. We trust the PR managers to establish their own approach to carrying out |
| 28 | +these responsibilities.) |
| 29 | + |
| 30 | +$(P In the text below, $(B APR) refers the Administrative PR Manager Role, $(B |
| 31 | +TPR) refers to the Technical PR Manager Role.) |
| 32 | + |
| 33 | +$(H2 Administrative Responsibilities) |
| 34 | +$(P In order to effectively carry out his responsibilities, the APR needs to be |
| 35 | +aware of which core contributors are responsible for which areas and which |
| 36 | +community members to contact when necessary to resolve issues, and have an |
| 37 | +understanding of the general direction the language and ecosystem are going |
| 38 | +(i.e., for any given PR, the APR should be able to answer the question, "Do we |
| 39 | +do this?").) |
| 40 | + |
| 41 | +$(UL |
| 42 | + $(LI $(B Maintain the contribution guide) - $(LINK2 |
| 43 | + https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md, the contribution |
| 44 | + guide) establishes best practices for submitting issues and pull requests. The |
| 45 | + APR should work with the TPR to evolve these details as needed and ensure the |
| 46 | + document is up to date.) |
| 47 | + $(LI $(B Triage issues and PRs) - ensure that each issue report is properly |
| 48 | + prioritized and, where possible, assigned to someone who can resolve it; |
| 49 | + establish criteria to ensure that pull requests get as much time as they |
| 50 | + need for a proper review before being merged (e.g., trivial vs. complex, |
| 51 | + routine vs. controversial, etc); establish criteria to close issues/PRs; |
| 52 | + recognize when a pull request should first be incorporated as a DIP; etc.) |
| 53 | + $(LI $(B Keep track of progress) - the APR should establish some means of |
| 54 | + keeping up to date on the status of every issue and PR in our system, and |
| 55 | + will be the primary point of contact for queries about the status of any |
| 56 | + issue or PR.) |
| 57 | + $(LI $(B Communicate with relevant parties) - communication is vital to |
| 58 | + ensuring the efficient handling of issues and pull requests. Contributors |
| 59 | + will need to be sought out to resolve issues that are not picked up |
| 60 | + voluntarily; non-trivial pull requests will need to be reviewed by an |
| 61 | + appropriate core contributor/maintainer; contributors will need to be kept |
| 62 | + abreast of the status of their contributions when they cannot be resolved |
| 63 | + quickly; etc.) |
| 64 | +) |
| 65 | + |
| 66 | +$(H2 Technical Responsibilities) |
| 67 | +$(P In order to effectively carry out the responsibilities of this role, the TPR |
| 68 | +needs a solid understanding of the architecture of our GitHub projects (i.e., |
| 69 | +for any given PR, the TPR should be able to answer the question, "Can we do |
| 70 | +this?").) |
| 71 | + |
| 72 | +$(UL |
| 73 | + $(LI $(B Ensure compliance with contribution guide) - each issue and pull |
| 74 | + request should meet the guidelines established in $(LINK2 |
| 75 | + https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md, the contribution |
| 76 | + guide). The TPR will work with contributors to ensure these guidelines are |
| 77 | + met (reduced test cases, proper commit message format, changelog entries, |
| 78 | + resolve merge conflicts, etc).) |
| 79 | + $(LI $(B Identify and resolve regressions) - sometimes bugs are reported |
| 80 | + that are regressions, but not marked as such. The TPR should identify such |
| 81 | + issues, attempt to pinpoint the source of all reported regressions, and take |
| 82 | + steps to resolve them (e.g., contact the author/reviewer of the offending |
| 83 | + PR).) |
| 84 | + $(LI $(B Review trivial PRs) - pull requests that need no specialized review |
| 85 | + should be reviewed and merged by the TPR.) |
| 86 | + $(LI $(B Fix trivial issues) - the TPR is free to fix trivial issues and |
| 87 | + submit such fixes as pull requests, but must request review from a competent |
| 88 | + reviewer.) |
| 89 | +) |
| 90 | + |
| 91 | +Macros: |
| 92 | + TITLE=Pull-Request/Issue Manager Responsibilities |
0 commit comments