>This feature is similar to Google docs presence and helps prevent unnecessary work and pings.

Right, I understand, and I think for developer tasks like reviewing code or reviewing design documents, that's a negative feature in docs.

When I'm reviewing someone's work (be it a design doc or a PR), I don't want them watching me as I do it. I want time to focus privately, and I want to be in control of when I share my feedback with them.

>In my experience, people generally want to know when someone is looking at their PR so they know whether they need to find another reviewer or follow up.

I'm having trouble imagining a scenario where that would be needed.

If it's an urgent PR that needs review ASAP (rare in my experience, but it happens), I'd ping them on another channel to get positive confirmation they're on it and understand it's urgent.

If it's a normal PR, and the norms on my team are that PRs are reviewed in <1 business day, and they're over the limit, and I'm blocked, I'd send them a ping to make sure they're on it. I guess Visibly would prevent me from pinging them if I caught them in the 60-90 min window where they're beyond the normal deadline but still in the middle of a review, but I'd expect those cases to be fairly rare.

What's the typical flow where the presence feature would save a ping?

>Can you expand a little more on this point? At my previous companies, almost all development and debugging was done through Chrome.

Through Chrome specifically or through a web browser? My teammates do a lot of their work in a web browser, but they use a variety of browsers.

I should clarify that I work with a team of freelance developers, so I don't like asking them to install unnecessary software on their systems. I definitely wouldn't ask them to install surveillance software, which it sounds like is what Visibly is.

We currently do code approve with CodeApprove, which everyone on the team likes. We do have to learn new UI flows, but they're pretty simple. It was a problem with Reviewable, which had a steeper learning curve.

>The default is blocking. You make something non-blocking by unchecking the box or writing "nit:"

Ah, okay. I like that behavior.

>The current status always visible in the thread header and footer. You can expand the history to see all statuses, but you don't need to do so to see the latest.

That sounds good, but my feedback was more about highlighting that as a first-class feature of the product. I don't think status history is an important thing to surface, so it might not be a worthwhile thing to highlight as a feature.

>Which aspects of metrics do you feel lead to that incorrect focus? The intention with the review time metrics is definitely not to speedrun, it is quite the opposite - with the review time you can see how much effort has gone into the review, and so it helps naturally push developers to smaller PRs and to also leave more thorough reviews. Without the time, it's really easy to review a 1000 line PR in less than minute because there's no accountability. With the time, it would be easy to spot these cases. This goes back to the classic meme of short PR == 20 comments and large PR === LGTM with no comments

Oh, I thought the PR times were only visible to the reviewer. It sounds like you're saying that the PR times are public because their purpose is to snitch on the reviewer to their teammates and reveal that they didn't spend enough time on the review.

Again, I feel like this is a big contradiction to the promise of "Visibly values privacy" because I definitely don't want a surveillance tool watching me do reviews and reporting my behavior to my teammates.

If the problem is that developers are speeding through reviews and rubber stamping them without really reading them, that's a culture problem and not a tooling problem. Attempts to reduce developer productivity down to simple metrics like "lines of code written" or "minutes per code review" are counterproductive.