From 99897c4310c072319a1414e481eb30588936c11d Mon Sep 17 00:00:00 2001 From: David Baumgold Date: Thu, 24 Apr 2014 09:11:14 -0400 Subject: [PATCH] Add example for how scrum teams spend time reviewing contributor pull requests --- .../en_us/developers/source/process/core-committer.rst | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/en_us/developers/source/process/core-committer.rst b/docs/en_us/developers/source/process/core-committer.rst index 30b491fb50..af486f5baf 100644 --- a/docs/en_us/developers/source/process/core-committer.rst +++ b/docs/en_us/developers/source/process/core-committer.rst @@ -38,9 +38,13 @@ 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. This is just a guideline, however: the teams can -decide for themselves how many contributor pull request reviews they want to -commit to. +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