Core committers (or simply, committers) are responsible for reviewing pull requests from contributors. This happens once the pull request has passed through a community manager and been prioritized by a product owner. As much as possible, the code review process for community contributors should be identical to the process of reviewing a pull request from another committer: we’re all part of the same community. However, there are a few ways that the process is different:
Each Scrum team should decide for themselves how to estimate stories related to reviewing external pull requests, and how to claim points for those stories, keeping in mind that an unresponsive contributor may block the story in ways that the team can’t control. When deciding how many contributor pull request reviews to commit to in the upcoming iteration, teams should plan to spend about two hours per week per developer on the team – larger teams can plan to spend more time than smaller teams. For example, a team with two developers should plan to spend about four hours per week on pull request review, while a team with four developers should plan to spend about eight hours per week on pull request review – these hours can be spread out among multiple developers, or one developer can do all the review for the whole team in that iteration. However, this is just a guideline: the teams can decide for themselves how many contributor pull request reviews they want to commit to.
Once a pull request from a contributor passes all required code reviews, a core committer will need to merge the pull request into the project. The core committer who merges the pull request will be responsible for verifying those changes on the staging server prior to release, using the manual test plan provided by the author of the pull request.
In addition to reviewing contributor requests as part of sprint work, core committers should expect to spend about one hour per week doing other tasks related to the open source community: reading/responding to questions in the Community Discussions , disseminating information about what edX is working on, and so on.
In order to expedite the review process and to have a clear and mutual understanding between reviewers and contributors, the following terminology should be used when submitting comments on a PR:
As an example, the following PR comment is clearly categorized as Optional:
"Optional: Consider reducing the high degree of connascense in this code by using
It is possible that after further discussion and review, the reviewer chooses to amend their comment, thereby changing its severity to be higher or lower than what was originally set.