| > 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. That's fair. I'll think about how I can address this longer-term. Would being able to enter a "privacy" mode that hides your presence help? > What's the typical flow where the presence feature would save a ping? The typical flow I envision is someone on the same team following up with a coworker after 30-40 minutes after that person has indicated that they will review. It helps them understand if they need to ping again as a reminder. The reason someone may ping in that window is because PRs behave like black boxes after the link is sent - they have no idea if someone is reviewing and how far along that reviewer may be are; the author just has to wait until the comments come. We're currently working on real notifications pipeline, so this won't be a huge use case in the future. A different use case where presence may be more useful is to prevent overlapping reviews when pings to codeowners teams are automatic. If you can see someone else is reviewing, then you can defer to them. > 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. I disagree on the surveillance comment - Visibly uses GitHub data that is readily available, augments it with the review time metrics, and allows you to see the progression over time. Beyond that, Visibly does not monitor your work; it does not track what sites you're on or how you do your work. Visibly is only active on github.com and only on PR pages atm. It also takes the most minimal permissions to do this. Visibly is there to help you and your team understand how much time and effort reviews are taking so you identify trends and better optimize processes. It's also there to help the IC represent their work come perf time - it's really hard to figure out what to write in a perf review when you have to sift through months of work and reviews. > Oh, I thought the PR times were only visible to the reviewer. PR times are visible to those who have read/write permissions on the repo. Just like they can see comments / reviewers, they can see status and time. It's just another decision point. > Attempts to reduce developer productivity down to simple metrics like "lines of code written" or "minutes per code review" are counterproductive. I agree and not what Visibly is doing. Visibly surfaces metrics to give you more insight. If you don't know how much time reviews are taking, it's hard to accurately estimate timelines, hard to understand the thoroughness of reviews you receive, hard to see the cost of tech debt / complex code, etc. Visibly provides knowledge that you can use to adapt and improve collaboration. |