You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

105 lines
4.1 KiB

  1. # ADR 72: Restore Requests for Comments
  2. ## Changelog
  3. - 20-Aug-2021: Initial draft (@creachadair)
  4. ## Status
  5. Proposed
  6. ## Context
  7. In the past, we kept a collection of Request for Comments (RFC) documents in `docs/rfc`.
  8. Prior to the creation of the ADR process, these documents were used to document
  9. design and implementation decisions about Tendermint Core. The RFC directory
  10. was removed in favor of ADRs, in commit 3761aa69 (PR
  11. [\#6345](https://github.com/tendermint/tendermint/pull/6345)).
  12. For issues where an explicit design decision or implementation change is
  13. required, an ADR is generally preferable to an open-ended RFC: An ADR is
  14. relatively narrowly-focused, identifies a specific design or implementation
  15. question, and documents the consensus answer to that question.
  16. Some discussions are more open-ended, however, or don't require a specific
  17. decision to be made (yet). Such conversations are still valuable to document,
  18. and several members of the Tendermint team have been doing so by writing gists
  19. or Google docs to share them around. That works well enough in the moment, but
  20. gists do not support any kind of collaborative editing, and both gists and docs
  21. are hard to discover after the fact. Google docs have much better collaborative
  22. editing, but are worse for discoverability, especially when contributors span
  23. different Google accounts.
  24. Discoverability is important, because these kinds of open-ended discussions are
  25. useful to people who come later -- either as new team members or as outside
  26. contributors seeking to use and understand the thoughts behind our designs and
  27. the architectural decisions that arose from those discussion.
  28. With these in mind, I propose that:
  29. - We re-create a new, initially empty `docs/rfc` directory in the repository,
  30. and use it to capture these kinds of open-ended discussions in supplement to
  31. ADRs.
  32. - Unlike in the previous RFC scheme, documents in this new directory will
  33. _not_ be used directly for decision-making. This is the key difference
  34. between an RFC and an ADR.
  35. Instead, an RFC will exist to document background, articulate general
  36. principles, and serve as a historical record of discussion and motivation.
  37. In this system, an RFC may _only_ result in a decision indirectly, via ADR
  38. documents created in response to the RFC.
  39. **In short:** If a decision is required, write an ADR; otherwise if a
  40. sufficiently broad discussion is needed, write an RFC.
  41. Just so that there is a consistent format, I also propose that:
  42. - RFC files are named `rfc-XXX-title.{md,rst,txt}` and are written in plain
  43. text, Markdown, or ReStructured Text.
  44. - Like an ADR, an RFC should include a high-level change log at the top of the
  45. document, and sections for:
  46. * Abstract: A brief, high-level synopsis of the topic.
  47. * Background: Any background necessary to understand the topic.
  48. * Discussion: Detailed discussion of the issue being considered.
  49. - Unlike an ADR, an RFC does _not_ include sections for Decisions, Detailed
  50. Design, or evaluation of proposed solutions. If an RFC leads to a proposal
  51. for an actual architectural change, that must be recorded in an ADR in the
  52. usual way, and may refer back to the RFC in its References section.
  53. ## Alternative Approaches
  54. Leaving aside implementation details, the main alternative to this proposal is
  55. to leave things as they are now, with ADRs as the only log of record and other
  56. discussions being held informally in whatever medium is convenient at the time.
  57. ## Decision
  58. (pending)
  59. ## Detailed Design
  60. - Create a new `docs/rfc` directory in the `tendermint` repository. Note that
  61. this proposal intentionally does _not_ pull back the previous contents of
  62. that path from Git history, as those documents were appropriately merged into
  63. the ADR process.
  64. - Create a `README.md` for RFCs that explains the rules and their relationship
  65. to ADRs.
  66. - Create an `rfc-template.md` file for RFC files.
  67. ## Consequences
  68. ### Positive
  69. - We will have a more discoverable place to record open-ended discussions that
  70. do not immediately result in a design change.
  71. ### Negative
  72. - Potentially some people could be confused about the RFC/ADR distinction.