Changes in README.adoc

[csacher]

No description provided.

[csacher]

Updated Intro

[cbeams]

@csacher, this is looking great. A couple bits of feedback:

1. I think it may be best to omit the list of roles, as added in fa644a1, because this is in the end just something that's likely to get out of date. Instead of doing this, just inform the reader that they can see the list of role specifications right here in the root of the repository (same place as the README.adoc file, i.e. in the same directory) and/or they can see the list of roles by browsing issues in the repository / looking at the board, etc. I could be convinced otherwise, i.e. that it is a good thing to list out the roles in the readme, but it's important to note that it adds maintenance burden to do so.

2. An AsciiDoc formatting thing: when you're doing lists, like the one in fa644a1, prepend each line with a dash, e.g.:

 - this 
 - that
 - other

If you fail to do this, then the items all run together as seen below:

3. Issues like the one mentioned above in (2) can be prevented by previewing the Asciidoc before submitting it. I recommend the Asciidoctor.js Live Preview Chrome extension for this. Check it out, let me know if you have questions.

4. I'll add a few more specific notes in subsequent comments

[cbeams]

I'd yank the word 'transparent' here, sounds a little buzzwordy. Maybe just 'complete overview' instead.

• ones => one's
• typo in facilitate

[cbeams]

We can probably shorten this series of steps to:

How to create a new role

1. Discuss and make sure there is consensus about the need for and purpose of this role in the #roles channel or elsewhere
2. Create a GitHub issue representing that will be used to track this role (see other role issues for examples)
3. Create and edit a 'specification' document for this role based on ROLE-SPEC-TEMPLATE.adoc. See the existing list of role specs and follow the naming convention.
4. Submit the new file as a pull request. Be sure to mention the role issue ID, e.g. Roles Maintainer #28 somewhere in the pull request title or description to ensure that the pull request shows up in the timeline of the role issue.
5. The roles repository maintainer will review your new role spec, provide any feedback, and merge it when ready.

[cbeams]

minor edits:

The owner of [a given] role is responsible for creating and maintaining their role description as an AsciiDoc file here in this repository. We call these descriptions role specifications.

[csacher]

Thank you.

[csacher]

Feedback implemented, table done, bonds according to spreadsheet (missing amounts for many roles)

[cbeams]

This is merged, now, @csacher. Check out the changes at https://github.com/bisq-network/roles#readme, and I'd recommend browsing through the recent commits at https://github.com/bisq-network/roles/commits/master to see what changes were made and why. Thanks for the session today working on all of this!