From da545a74f1358a8411b03d9698ed8ae4284383c3 Mon Sep 17 00:00:00 2001 From: Joe Walker Date: Mon, 29 Jan 2018 14:27:41 +0000 Subject: [PATCH 1/2] Minor newline->space change to clarify bullet nesting --- text/0006-architecture-review-process.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/text/0006-architecture-review-process.md b/text/0006-architecture-review-process.md index 153b2ab..9c2d63f 100644 --- a/text/0006-architecture-review-process.md +++ b/text/0006-architecture-review-process.md @@ -28,8 +28,7 @@ For both a Roadmap Review and a Design Review the **timetable** is as follows: - For a Design Review this will be an experienced engineer in the problem domain outside of the team willing to put time into the problem. As engineers don’t review their own code they shouldn’t review their own designs. The principle is to get the most informed and least biased feedback possible. * Optionally, for larger reviews, find someone to **chair** the review. This can facilitate the process (i.e. scheduling the meeting, managing the clock, ensuring minutes are taken, etc.) and enables the reviewer to concentrate on the review itself. The rest of this document uses 'chair' for the administrative role. For smaller reviews the reviewer also does the tasks of the chair. -2. The team produces a **Review Packet** designed to document the proposal identified in step 1. The production of the Review Packet is expected to be collaborative and iterative to ensure that the review focuses on the key issues so the team presents its best case. This is particularly true of a Roadmap Review where the consequences of the review are likely to be more significant. -The Review Packet includes: +2. The team produces a **Review Packet** designed to document the proposal identified in step 1. The production of the Review Packet is expected to be collaborative and iterative to ensure that the review focuses on the key issues so the team presents its best case. This is particularly true of a Roadmap Review where the consequences of the review are likely to be more significant. The Review Packet includes: * A lay summary of the problem space which is focused on defining a shared language and identifying the key forces behind the problem * A list of the groups directly affected by the proposal to ensure that the review meeting includes representatives from those groups. * A vision of what the project will achieve on completion From 081bbc54da8be56fe35bed6ac0639009591f9ca5 Mon Sep 17 00:00:00 2001 From: Joe Walker Date: Mon, 29 Jan 2018 15:03:20 +0000 Subject: [PATCH 2/2] Lightweight reviews might not need a panel (or even a meeting) --- text/0006-architecture-review-process.md | 1 + 1 file changed, 1 insertion(+) diff --git a/text/0006-architecture-review-process.md b/text/0006-architecture-review-process.md index 9c2d63f..f30d7e0 100644 --- a/text/0006-architecture-review-process.md +++ b/text/0006-architecture-review-process.md @@ -55,6 +55,7 @@ For both a Roadmap Review and a Design Review the **timetable** is as follows: - Short opening statement by the team on the current state of play - Discussion of Questions and Answers (see 3. above) - A step back to discuss if the proposal is right in the wider context + * A lightweight review might not need the input of others, and ultimately, might not even need a specific review meeting. The review meeting should be a discussion of the issues, but should avoid feeling pressured to make a decision. The goal is to understand the issues raised by the question(s) and the background from the review packet, and to add to it wisdom from the people at the review. The meeting may decide to alter the questions and undergo a subsequent review. We should be very open about conversations that happen after the review meeting.