code documentation for the new client app

[cfm]

One of my favorite things in the Python ecosystem is the convention of docstrings. Even without the use of a tool like Doxygen or Sphinx's autodoc to render external documentation with formatting and call/caller graphs, Python docstrings encourage a good habit: If you've encapsulated some code in a function, method, class, or module, then you should take the time to document it what it is, how it works, and how it should be used. Anecdotally, I've found that a codebase with thorough docstring documentation is kept documented as it evolves, including at the level of internal implementation details.

I'd like to see us carry this habit over into the new SecureDrop client while its TypeScript/React codebase is still small and approachable. I'd support fully adopting something like TypeDoc, but to me the tooling is secondary to the habit and the convention. I suggest we:

1. adopt a convention;
2. document it (a) in securedrop-dev-docs and (b) in securedrop-client's pull-request template; and
3. make time in an upcoming sprint to document the codebase so far, whether (a) one person takes this on or (b) each contributor documents the extant code they've written

[legoktm]

+1 from me, I would suggest that we just go ahead and try it (step 3) and see how it works out, and then formalize it (steps 1 and 2) once we have a better sense of the utility and cost.