Default Action (Reply vs Start a Review) on Code Review Comments Changed

[ssigwart]

🏷️ Discussion Type

Bug

Body

Starting around Sept 22, the default action for submitting PR comments when reviewing a PR changed. It used to be that in the File Changes tab (/changes URL), the default action was Start a Review. So if you hit Cmd+Enter on MacOS, it marked the comment as pending until you submitted the review. When writing a new comment, that is still the case. However, starting on Sept 22, I noticed that if you have not started a review yet and try to comment on an existing commit from the Files Changed tab, the default when you hit Cmd+Enter is to reply immediately. This is causing a lot of excess notifications and comments being submitted before the full review is completed.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[MooreHaww]

When you reply to an existing thread and no review is pending, GitHub treats it as a standalone reply and sends it right away. A new line comment gets the “Start a review” treatment, which is why the two feel inconsistent. Once a review is pending, replies get added to it, so the shortcut only misbehaves for the first action in a session.

The workaround that has worked for me is to start the review with a new comment before touching anyone else’s threads. Even a throwaway comment on a line you actually care about does it. After that, replies are batched and nothing goes out until you hit Finish your review. The catch is that if the first thing you do is answer a thread, that one goes out immediately and there’s no undoing the notification.
I’d also stop relying on Cmd+Enter for that first reply and click the button explicitly, so you can see whether it says reply or add to review before it fires. The shortcut just fires whatever the default is.

[ssigwart]

Yes, exactly. It's inconsistent and a change from how it behaved for years. It has been over 3 weeks and I still haven't been able to break the habit of hitting Cmd+Enter. I've used those workarounds, but the the problem is remembering to use that instead of instinctively hitting Cmd+Enter.

[MooreHaww]

I’d move the fix to a moment you do remember instead of the moment you forget tbh, but you can try...

1. Start the review as soon as you open Files changed. Before you read anything, add one throwaway comment on any line, like “review notes”. That puts a pending review in place, so every Cmd+Enter after it, including replies, goes into the batch. Delete the comment before you submit. It becomes part of opening a PR rather than something to recall mid-review.

2. Get rid of the dangerous shortcut. A small userscript (Tampermonkey or similar) can catch Cmd+Type in the reply boxes and do nothing or click on the “add to review” button. I haven't tested one against the current UI, and GitHub's markup changes so you'd have to check the selectors.

3. Check (review) in your editor. The GitHub Pull Requests extension lets you collect comments into a review in VS Code; it shows a pending state. Your reflex ends up in a tool where "pending" is the default and you have to submit explicitly.

None of these is perfect, but the first needs zero tooling and works the same on every PR
(It’s also worth keeping the feedback thread open, since it’s a real regression for people who review all day (just saying))