No worries, feedback of any kind is always welcome, and direct if diplomatic feedback is the best -- which is exactly what you wrote. :) Let me know if you'd like to chat directly at any point, we love talking to our users.

> 1) It's not obvious enough that a user is supposed to declare a state after writing a response

That's because you don't need to declare a state after writing a response. :) The basic workflow is simple: click the button if you're in favor of ending the discussion, otherwise write a response. For more advanced workflows, yes, you can explicitly select a disposition from the dropdown, or prefix your message with a magic keyword to do so automatically.

> For (2), this is more personal opinion, but I think comment threads are similar to Github issues in that there only need to be two states: closed or open.

You're conflating two separate things: each discussion has a state (open -> in progress, closed -> resolved in Reviewable parlance), but so does each participant. The discussion's state is a function of all the participants' states, allowing for a consensus to develop in multi-party reviews without giving any one person the power to unilaterally close the discussion. There are three basic participant states:

Blocking -> prevent discussion from resolving Satisfied -> in favor of resolving discussion Discussing -> neutral; not my monkeys, not my problem

The other two states you mentioned are specialized and affect other features besides the discussion state:

Working -> like Blocking, but also "keeps the ball in your court", so Reviewable knows you're still responsible for further progress on this discussion and won't list it as needing a reply from other participants; it's usually employed by a PR author who agrees with a request but wants to reply with further details before they've actually done the work.

Pondering -> this prevents a draft from being sent when you publish; useful for "notes to self" as you read through the code that may or may not become actual issues you want to raise, and that you don't want to accidentally publish as-is.

It's not a simple system but we figure you've got GitHub for that, so we choose to err on the side of powerful.

> My somewhat controversial opinion is that the author and reviewer should trust each other enough that the author can respond to a note and mark it resolved without awaiting confirmation from the reviewer who wrote the note.

You can do that too! If you initiate a discussion as Discussing, then if the author clicks the Done button (switching to Satisfied) the discussion will automatically be resolved, with no further input from you. You can change your default disposition for discussions created as a reviewer if that's how you prefer to work; see https://docs.reviewable.io/discussions.html#resolution-workf... for details.

> In Critique, it was easy to see at a glance whether a note was active or resolved

In Reviewable, resolved notes are collapsed into the title bar (if just resolved) or into a gutter icon (afterwards), so usually you won't even see them. I'm confused when you say that you can't tell which are active and which are resolved, but perhaps we differ in our understanding of what "resolved" means.