|
| 1 | +--- |
| 2 | +collaborating_projects: |
| 3 | + - coala |
| 4 | + - GitMate |
| 5 | +desc: "Notify developers about pull requests that propose changes in their specific field of expertise" |
| 6 | +difficulty: medium |
| 7 | +initiatives: |
| 8 | + - Research |
| 9 | +issues" : [] |
| 10 | +markdown: assign_pull_requests.md |
| 11 | +mentors: |
| 12 | + - fneu |
| 13 | + - sils |
| 14 | +name: "Automatic Assignment of Reviewers for Pull Requests" |
| 15 | +requirements: |
| 16 | + - "At least one patch to coala or GitMate should be accepted and merged." |
| 17 | + - "Familiarity with [IGitt](https://gitlab.com/gitmate/IGitt) is advised" |
| 18 | +tags: |
| 19 | + - Workflow |
| 20 | + - GitHub |
| 21 | +--- |
| 22 | +Changes to the source code of a software can bring great improvements as well as |
| 23 | +great deteriorations. Bugs are hard to spot, especially for developers that |
| 24 | +have little experience with the code at hand. Important details of the implementation |
| 25 | +can be hard to understand and easy to overlook. |
| 26 | + |
| 27 | +It is therefore important that every change proposed by any developer gets reviewed |
| 28 | +by an experienced dev before it is merged into the software source. The developer |
| 29 | +best qualified for proposed changes is oftentimes the author of the previous |
| 30 | +implementation or somebody that has worked on it. These people have experience with |
| 31 | +the problem at hand as well as the exact code that is being changed. |
| 32 | + |
| 33 | +Not every dev can follow all the proposed change to a project all the time, especially |
| 34 | +once the project grows past a certain size. Therefore, a programmer might miss the |
| 35 | +opportunity to give valuable input on a matter he has great experience with. |
| 36 | + |
| 37 | +The goal of this project is to prevent this from happening and notify developers when another |
| 38 | +developer proposes changes to code they have authored or worked on. The Code altered in |
| 39 | +the pull request at hand should be evaluated for authorship as, i.e., indicated by the `git blame` |
| 40 | +command. The most appropriate developer for reviewing the proposal should then be selected and |
| 41 | +notified. |
| 42 | + |
| 43 | +The scope of this project is aimed at a scientific research thesis. Therefore we would like to see a |
| 44 | +clearly determined and structured approach as to how the appropriate developers will be selected. |
| 45 | +Most appropriate would be a literature-backed approach that is implemented and verified throughout the |
| 46 | +execution of this project. |
| 47 | + |
| 48 | +#### Milestones |
| 49 | + |
| 50 | +##### PROPOSAL |
| 51 | + |
| 52 | +* A credible strategy for selecting developers is proposed |
| 53 | + |
| 54 | +##### EVALUATION |
| 55 | + |
| 56 | +* The data of previous developer activity has been collected and processed |
| 57 | +* A toolchain is in place to automatically collect and evaluate the data of incoming pull requests |
| 58 | +* The proposed developer selection algorithm has been implemented |
| 59 | +* The developer selection done by the algorithm has been verified or refuted through real world testing |
0 commit comments