Merge pull request #61 from joewalker/review-update-2

Add note about lightweight reviews

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
@@ -56,6 +55,7 @@ The Review Packet includes:
       - 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.