[piotrkaminski]

Hey, thanks for the feedback on Reviewable! You make some really good points:

> Steep learning curve

Guilty as charged. I think it's cohesive and efficient once you learn it but the learning curve is quite steep. We keep trying to think of ways to flatten it a bit but haven't had any great ideas so far. If you have thoughts on this -- or could point us to a great UX designer with dev tools experience -- it would be much appreciated!

> Performance

There are some obvious things we're working towards to improve it but these days most reviews load in 3-4 seconds for me, even on a not-very-awesome laptop. What kind of platform are you seeing 10 second load times on, and how's your Internet latency to us-central? Please open an issue and we can work through it together.

> Complicated configuration

Yeah, there's a lot of support for legacy and highly customized workflows in there. But these days the primary and default integration is with GitHub's approve/request changes workflow, which gives you one-click approve -- have you tried using that? (Efficient multi-repo config updates are also on the todo list, but never quite rose to the top.)

> Excessive permissions

This is an unavoidable side-effect of using GitHub's OAuth authorization mechanism. GitHub Apps allow finer-grained permissions but they didn't exist when we created Reviewable and don't have a good answer for listing PRs, which would make our dashboard significantly less useful. We do have a transition planned out but at this point our main customers are enterprise folks who run their own GHE Server and don't much care about fine-grained permissions, so the ROI doesn't pencil out.

> Thread state is unclear

Huh, I'm surprised by this one. The basic flow is: 1. Reviewer creates a discussion (disposition defaults to Blocking). 2. Author responds with questions/comments (disposition defaults to Discussing). 3. Reviewer clarifies (disposition unchanged) or clicks the big Resolve button (disposition changes to Satisfied, discussion is resolved). 4. Author addresses the comment and clicks the big Done button (disposition changes to Satisfied). 5. Reviewer checks and, if satisfied, clicks Resolve (disposition changes to Satisfied and discussion is resolved).

Basically, at every step you either reply to keep the discussion going, or click the button to indicate that you're fine with closing it out. You shouldn't even need to care about the specific disposition unless you're trying to run more advanced workflows.

> No development

Yeah, I pretty much abandoned the blog and should probably take it down. However, we do ship new features regularly and post updates on Headway [1]. These should also pop up as the "red circle new stuff counter" in the UI, but perhaps your browser is blocking that third-party connection. (Headway only gets major feature posts, but there's a lot more work going on in the background that's only reported on the enterprise changelog [2].) I'm not a fan of spammy email newsletters so we don't send those.

Again, thanks for the feedback, and don't be a stranger -- it's easy to reach us through email, chat, issues, etc., and we respond promptly to every message. Even if we have to hunt them down on HN. :)

[1] https://headwayapp.co/reviewable-changelog [2] https://github.com/Reviewable/Reviewable/blob/master/enterpr...

[mtlynch]

Thanks for the gracious responses, Piotr! I didn't write that with you in mind, so I hope it doesn't come across as too critical. I have been a happy customer for 7 years.

>>Thread state is unclear

>Huh, I'm surprised by this one...

>Basically, at every step you either reply to keep the discussion going, or click the button to indicate that you're fine with closing it out.

I think there are two problems here:

1) It's not obvious enough that a user is supposed to declare a state after writing a response 2) There are more states than necessary

For (1), the UI flow doesn't hint to the user that they're supposed to do anything after they type their reply. I just tried it and I see this:

https://i.imgur.com/DimycTB.png

It sounds like you're saying the expectation is that users click the circle at the upper right and then choose a state, but that hasn't been obvious to anyone I've introduced to Reviewable.

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. The states Reviewable offers to me as the author are:

(1) Discussing, (2) Satisfied, (3) Blocking, (4) Working, (5) Pondering

1, 3, 4, and 5 are all "open" for my purposes, and (2) is closed. It's rare in my experience for a developer to respond halfway through a round of review to say they're still working on or pondering a comment, so I don't need dedicated states for that. They can just keep it open and write a comment like "still working on this one!" I don't see a difference between (1) and (3), as all notes are blocking until they're resolved.

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. It's rare in my experience for an author to incorrectly resolve a note, and when it happens, the reviewer can just reopen it and say, "Hey, I think there was a misunderstanding on this one, and the changes haven't addressed this note." I think forcing the flow into "Discussing" -> "Pending resolution" -> "Confirm resolution" just adds needless friction.

>You shouldn't even need to care about the specific disposition unless you're trying to run more advanced workflows.

We don't, but I see it as a missed opportunity because there's useful information there.

In Critique, it was easy to see at a glance whether a note was active or resolved (active notes had an orange background and resolved notes had a gray background IIRC). In Reviewable, we have to read all the notes more closely to see which are active and which are resolved.

>I'm not a fan of spammy email newsletters so we don't send those.

I don't like those when it's baldly trying to wring more money out of me, but I like it when vendors tell me what's going on and how they're improving the product.

[piotrkaminski]

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.