3. Design docs

3.1. Introduction

Design docs are used to introduce a new feature to the existing code. They are created during the design process and strictly before the actual implementation. Their significance is two-fold:

• They allow members of the same team to understand what is the new feature that their team member wants to insert, as well as quickly evaluate its design. This means that there is zero communication overhead [1] between them while remaining in sync. Moreover, it makes it easier for another member to provide feedback.
• Adhering to the notion that you only understand something when you have to explain it to others, writing down the design of a new feature can have a beneficiary rubber duck effect on the author and thus prevent feature design shortcomings that were not foreseen.

3.2. Index tree

We present on the list below the design docs so far:

• 1. Archipelago logical entities and commands
  • 1.1. Current state
  • 1.2. Objective
  • 1.3. Archipelago topology
  • 1.4. Logical entities
  • 1.5. Volume operations
  • 1.6. Management commands
• 2. Design doc for namespaces in cached
  • 2.1. Current state
  • 2.2. Design overview
  • 2.3. Advanced design issues
  • 2.4. Implementation details
• 3. Design doc for flow support in cached
  • 3.1. Current state
  • 3.2. Objectives
  • 3.3. Flows
  • 3.4. Design overview
  • 3.5. Design of components
  • 3.6. Cached operations
• 4. Design doc for xseg signaling
  • 4.1. Current State
  • 4.2. Proposed changes
  • 4.3. Implementation details
  • 4.4. Typical usage scenario
• 5. Design doc for xindex
  • 5.1. Current situation
  • 5.2. Design overview
  • 5.3. Implementation details

[1]	The overhead of writing the design doc is a whole different story...