# Exploration Reports

Exploration Reports are a (loose) style of document we use in order to gather thoughts, share early drafts of concepts, and begin to solicit feedback.

  • There is minimal restriction on formatting;
  • The goal is to produce referenceable material;
  • Content may be single-author and consensus is not a prerequisite;
  • Dates are used to provide rough contextualization of how freshly handled a matter is.

# format

Exploration Reports don't have a strict format, just general intentions. Part of the purpose of exploration reports is to make writing possible and lower the barriers to entry to get something written and sharable; overly strict formats and formalizations would be antithetical to this purpose.

# producing reference material

Remember, a goal of these documents is to produce documents viable to use as touchpoints in discussion, and not necessarily serve as the discussion format itself. For that reason, we treat them as (roughly) append-only; and, typically, exploration reports will have a single author (more on that in the next section).

# non-consensus

Exploration Reports are intended to encourage writing things down and forming bodies of thought which we can reference in the future -- and do so without putting any burdens of consensus-seeking up-front (which we observe can become a barrier that makes sharing and recording early design processes harder).

Therefore, it's not just acceptable but even typical for Exploration Reports to have a single author. Correspondingly, Exploration Reports don't need to reach for full solutions, which means as long as the report covers reasonably interesting ground, it should often be possible to merge them with minimal turnaround time.

You can find similar patterns used in other communities described here:

  • https://github.com/golang/go/wiki/ExperienceReports