Very cool! I like the idea of tracking time per active reviewer -- in addition to bringing visibility to the work of reviewing code, it doubles as a signal of how easy a particular PR was to understand. That's potentially valuable feedback to both the author of the code (e.g., if smaller PRs would be helpful), as well as to the team if there are parts of the codebase that systematically take longer to grok.
>See reviewer presence so that you can see if someone is already reviewing and avoid unnecessary pings.
>Visibly values privacy and security above all else
These two things seem squarely at odds. Personally, I don't want my code review tool announcing to developers when I'm looking at their PR.
The fact that it's a Chrome extension would also be a big blocker for me. I run a dev team, and I wouldn't ask any of my teammates to install a browser extension to participate in code reviews, especially one that's only available for Chrome.
I care a lot about code reviews [0], but the features here don't really resonate with me.
- Blocking vs. non-blocking: This is useful, but the default should be that a comment is blocking. Otherwise, it makes the default that all the reviewer's notes are optional unless they go out of their way to mark them as important.
- Thread status history: I think the status history is much less important than the status right now. In other words, I'd like to know if a review is blocked on the author or reviewer. I'm not that interested in what the status was yesterday.
- Metrics: I worry that these focus on the wrong thing. I'm trying to maximize usefulness of my review rather than speedrun through them to improve my PR time.
One of the huge gaps in Github's tool is the ability to do multi-round reviews (e.g., "show me what's changed since my last round of notes"). You can kind of bend Github to show you the right diff, but then it can't show the comments in a sensible way. Two tools that solve this well are CodeApprove[1] and Reviewable[2].
Wow this looks great. I really like the additions of presence and the stats about review times. It seems seamlessly integrated.
As you might be able to tell from my username, I’m the founder of CodeApprove (codeapprove.com) which is meant to fix a lot of the same problems you’re going through with Visibly. I’m also passionate about code review and code review tools in general so I’d love to chat sometime, feel free to use the email in my profile.
What makes this not just another tool to be abused by micromanagers?
Not everything needs to be measured, and indeed, measuring some things can cause more harm than good, especially as the measurements are often devoid of any kind of context.
I often start reviewing in GHs UI but depending on the complexity of the code I might need to go to vscode for better readability and intellisense. Does Visibly have an extension for that too?
Is there a link to the source code somewhere?
One question and one comment:
Q) What's the difference between a blocking comment and a "normal" comment + rejecting the PR?
C) Exposing metrics like "Review time per reviewer" may, at the wrong hands, incentivise the wrong behavior. For example, a team lead may view long review times by a particular reviewer as them being slow, whereas they are just more thorough. Tracking the total review time for the PR (aggregating the times from multiple reviewers) is more useful.