Draft a Documentation Charter

[gdjohnson]

Per conversations in #4353, we should establish a Documentation Charter. This charter would be a high-level synopsis of our goals in establishing a documentation system.

Some issues that should be addressed in the charter:

• Who are the docs for?
  • This is perhaps the question of the charter, from which all the other answers flow...
  • Balancing internal developers' needs and outsider contributors
    • Who are our outside contributors? Do we have case studies from the past we can look at, to think this question through?
  • Pushing upstream to the documentation of libraries and APIs we use
• What is the scope of documentation?
  • Right now, we've scoped documentation to engineering processes & codebase, bracketing out (for instance) the Design System flows
  • Documenting the organization (processes, systems) vs documenting the codebase
• What is the philosophy of how we approach documentation?
  • Concision vs comprehensiveness
  • Less is more
  • Automated vs manual systems
  • Engineer-led vs chronicler-led

[gdjohnson]

Noting that this charter will necessarily be a draft, a means of soliciting input from leads and stakeholders as to the macro-functions of our docs.