[noise] Document status, process, and governance

[Trevor Perrin]

As we juggle more documents we'll need ways to indicate document
status, and some process for making status decisions and controlling
document revisions.

This raises questions of governance, which we haven't dealt with before.

Here's some proposals:


Document status
----------------
Each document would have a pair of labels:
 - official or unofficial
 - stable or unstable

Official documents represent probable good ideas and directions the
Noise ecosystem should evolve in, and are controlled by the "Noise
project" (whatever that means - see later).  Official documents will
be linked from the website.

Unofficial documents will only be linked from the wiki, and are
controlled by whoever writes them.

Stable documents can still be revised and added to, but won't have
incompatible revisions made unless security flaws are discovered, or
if there is widespread consent from existing users for the change.

Unstable documents are at risk of incompatible changes any time the
author thinks it's a good idea.

The progression would be unofficial/unstable -> official/unstable ->
official/stable.

There might be an additional maturity status for finished documents
which won't have further revisions, but we can worry about that later.

In terms of current documents:
 - The Noise spec would be "official/stable".
 - NoiseSocket is probably close to "official/unstable"
 - Our other docs (Rhys's hybrid forward secrecy; David's disco) would
be "unofficial/unstable".


Revision process
----------------------
Official documents would be under the control of the "Noise project".
Official documents would live under https://github.com/noiseprotocol/,
and the "Noise project" would assume responsibility for document
contents, and take either an "editor" or "joint authorship" role.
This allows the project to perform copy-editing and enforce quality
control and stylistic consistency on official documents.

The Noise project would also decide when to promote a document to
official and stable status.


Governance
-----------
Someone or some process needs to execute the "Noise project" role.

I'll propose the following:

 * I execute the "Noise project" role for now, meaning I make
decisions on document status and handle editing, merging changes, and
publishing revisions for "official" documents.

 * Decisions and edits should be made with consensus of affected
parties, as far as possible.

 * We revisit the topic of "governance" in a year to see if we want
anything different.

This would basically be a "benevolent dictator for now" model, with
the possibility of changing to a more democratic model in future
(steering committee or somesuch).

Setting up a more complicated process would take time and effort, and
might not produce better outcomes, since I think I have a pretty good
sense for what our tasks are for next several months.


Anyways, this would add a good bit more structure and clarity to our
efforts, which I think would be helpful.

It's a pretty Trevor-centric proposal though, so it's not surprising I like it.

It's definitely worth discussing governance some more - and
alternative proposals welcome! - since it's a topic we haven't engaged
with before.


Trevor