Distinguish 'primary' and 'secondary' role owners where appropriate

[cbeams]

Generally speaking, Bisq DAO roles should have at least two owners, in order to ensure that operational know-how, passwords, keys and other secrets are "backed up" in at least two brains instead of just one. Basically, we want to avoid the situation where any one contributor is a single point of failure for the Bisq DAO.

With that said, some roles do not require active participation from two or more role owners. It is enough, in many cases, for a "primary" role owner to be identified, and for this person to carry out normal duties, respond to requests, and so forth by default, and for the "secondary" role owner to be "on call" should the primary role owner become indisposed for any reason.

Here are a few examples of roles where a primary / secondary distinction makes sense:

• @alexej996 is the primary Forum Admin role owner, and @Emzy is the secondary. Emzy has all the keys to Discourse and the box it lives on, knows how to administer things, etc, but @Emzy does not do anything with the forum on a day-to-day basis. He would only respond to a request if asked explicitly to do so.

• @mrosseel is the primary Freenode Admin role owner, but @ManfredKarrer and @cbeams both have op status in the Freenode #bisq and #bitsquare channels, so are secondary role owners.

• @ripcurlx is the primary YouTube Admin, but @cbeams has full access too.

The proposal here is simple: Role owners should keep their issue descriptions up to date with regard to which assignees are primary and which are secondary. That is, all role owners should be assignees to their respective GitHub issues, but the GitHub issue description should call out which are Primary and which are Secondary. You can see an example of this in bisq-network/roles#56 (YouTube Admin) and bisq-network/roles#22 (Freenode Admin).

[ManfredKarrer]

We probably should apply that to the seed nodes, prices nodes, btc nodes to have a backup of the onion keys. So in that case the secondary would only keep a copy of the onion key and could in emergency case step in by starting up a own service. No need to share access to the actual machines as if a new onion service is published the new one will be picked anyway in case the old one would still be running.

[cbeams]

Closing as approved. We're still rolling this change out across the various roles. In any case, I'll capture the decisions made here when I write up the doc on roles (bisq-network/bisq-docs#46).