Clarify and refine the proposal process

[cbeams]

We've had the proposals repository here for a number of months, and we've used it in a variety of ways over that time. I'm proposing the following clarifications and refinements to the proposals repository and to the overall proposal process to help everybody use this resource to best effect:

1. Write proposals for specific changes you want to see in Bisq and the Bisq DAO, especially for changes that would benefit from or otherwise require feedback and agreement from other contributors. For example, proposals are a good way to get feedback about introducing a whole new Bisq component or making a big change to an existing one, and proposals are good for making changes to the way we work together under the Bisq DAO. Proposals are not so good, however, for discussing smaller or more low-level changes to existing components. That kind of thing should be done with normal issues and/or pull requests in components' dedicated repositories.

2. Aim for rough consensus, and avoid voting on proposals whenever possible.

3. Write proposals in a way that makes it as easy as possible to achieve rough consensus. This means that proposals should be as simple, focused, concrete and well-defined as possible. Your goal as a proposal author should be to make it as easy as possible for your fellow Bisq contributors to understand and agree with you about your proposal.

4. Get to rough consensus using 👍 and 👎 reactions to proposal GitHub issues. If you give a 👎, say something about why. Explain your objections, so they can be addressed. If you don't explain your objection, don't be surprised when it gets ignored. If you do explain your objection, you should expect it not to be ignored; that is, proposal authors should address all reasonable concerns and objections.

5. When reviewing proposals, ignore the ones you don't care about or don't know enough about to have an opinion on, and do not hesitate to give a 👎 reaction to proposals you do not want to see enacted.

6. Start by writing a proposal issues like this one. Only write a proposal documents if and when necessary.

7. As the author of a proposal, you are 100% responsible for that proposal's success. It is not the @bisq-network/proposals-maintainers' job to see your proposals succeed. If people aren't responding or reacting to your proposal, it's your job to solicit that feedback more actively.

8. Never assume that anyone other than yourself is going to do the work described in your proposals. If your proposal does place expectations on other contributors, or requires them to change their behavior in any way, be explicit about that.

9. @bisq-network/proposals-maintainers should assign proposals to their original authors to make it clear who is responsible for them. Assignments can be changed on request, e.g. if someone is handing off a proposal to be managed by someone else.

10. Proposal owners should aim to get to rough consensus within a week or two. That's enough time for everyone who might care to have a look and comment and for any necessary discussion to ensue. Much longer than that and the proposal will probably "die on the vine" and ultimately get closed due to inactivity.

11. @bisq-network/proposals-maintainers should close proposals after a month of inactivity. Proposals can always be re-opened. The purpose is to keep the set of open proposals small and with a high degree of "liveness" to make it easy for people to review open proposals without risking wasting their time. Basically, the proposals maintainer's job is to make sure there are no "broken windows", that stale / inactive proposals get closed, and that existing open proposals follow whatever best practices we decide on like the ones above.

12. @bisq-network/contributors should click the "Watch" button on the proposals GitHub repository to be notified of new proposal issues and comments on existing proposals. Individual proposals issues you don't care about can always be muted / unsubscribed from.

The point of all this is to make proposals simple and easy to use for everyone involved. As we move away from co-founders being the prime movers and decision makers, these proposals will only get more important. Let's start using them more systematically now, and start building the kind of decision-making culture we want to see in Bisq's future.

So, if you're on board with the clarifications and refinements above, please give this issue a 👍 below. If not, please give it a 👎 and explain your concerns or objections. Thanks.

[cbeams]

It looks like we have consensus on this proposal, and I'm about to close it as was:accepted. To document these changes, I've just created the pull request at bisq-network/bisq-docs#40.

[cbeams]

Closing as approved. These changes are documented at https://docs.bisq.network/proposals.html, and as the acting proposals maintainer, I'll begin enacting these changes effective immediately.