Redesigned Conversations | Hacker News Reader

Redesigned Conversations

github.com

126 pointsbencevans44 comments

This looks nice, but doesn't address my main complaint with the conversation/PR system: there's no way to batch comments.

When doing code reviews, you can sometimes have upwards of 10 or 15 comments. In the current system this means 10 or 15 emails in everybody's inbox. It's also hard to work through a PR without letting everybody know when you're actually finished.

I would love to be able to comment on things as I read through them, then after I finish publish all of the changes and have them go out as one email.

Another advantage to this system is that reading and commenting becomes less prone to these sort of comments:

"Where is X defined" "Ah I see, this is where X is defined, disregard older comment"

A publish system allows you to basically stage comments before publishing. I used rietveld before github and this alongside side by side diffs was killer.

Sounds like you want something closer to Gerrit, where you can do line-by-line code reviews on an entire commit along with an overall comment, and the whole thing goes out as one mail.

Likewise. I find myself reluctant to comment on minor problems because I don't want to send another email.

We use http://phabricator.org/ at work and I absolutely love it, but sometimes I'm forced to use GitHub for things and I get sad.

I found a :thumbsup: emoticon comment successfully tells everyone I'm finished reviewing a pull request.

:+1: is a good shortcut :)

Is there a list of those somewhere? I've spent far too much time typing colon followed by random characters just to explore the many options.

There sure is! http://www.emoji-cheat-sheet.com/

I don't get any such emails. Maybe I turned it off years ago and forgot about it. Anyways, I wouldn't let an optional setting influence the way you work.

To be clear, I find the emails very useful (this is primarily from the perspective of me using Github for work--it's nice to know when somebody has reviewed your code). But I want one, not 15, and after the code reviewer has finished.

I agree this is a big problem. I've had cases where I'm still reviewing stuff but the person whose code was under review just fixed my first few comments and then submitted it while I was still writing the rest.

I know this is partially a process problem, but having batched emails would certainly help make it more obvious.

Google's reitveld is a bit of a mess but at least it gets this part right.

On the topic of github emails, I'd love the ability to set an email for notifications on a per repository, instead of just per organisation basis.

Can't you turn off emails but still have GitHub notifications on the website?

You can. I had to do this because my GitHub username (like my HN one) is just my name ("rob") and I was getting notifications from people using @rob in their comments/replies instead of the person's actual GitHub username. :)

So I use github enterprise and use the review tool a lot.

It has improved our overall code review experience, but there is a few things which have proved problematic and even have caused major headaches in the last year or so.

1. No Side by Side diffs. 2. Pushing new commits will often collapse conversations from the review. (i.e these conversations are folded)

Really, I want some way to look at my PR and say hey I've addressed all the comments on this pull request, and I am good to merge.

This is not even getting into what happens if you rebase your branch and then force a push to the remote.

For problem 1, I use this extension https://chrome.google.com/webstore/detail/octosplit/mnkacica... It's not quite the side-by-side diff that I want (like Meld http://meldmerge.org/) but it does help.

When things are messy enough that I want to rebase a branch, I generally create a new branch and new PR, and close the old PR with a comment linking to the new PR. I also put a link to the old PR in the description of the new one, so people can easily go back and look at the old discussion.

In other words, rebasing is a big enough change that I feel it's appropriate to restart the PR.

If you are linking the requests with a comment on each end, I'm not sure I see the benefit to just pushing the rebase into an open request. Is there a real difference?

I wrote a Chrome extension that supports side-by-side, syntax highlighting, and some other stuff: https://chrome.google.com/webstore/detail/github-side-by-sid.... It draws a lot of inspiration from having used Phabricator. For anyone interested, the source code is at: https://github.com/mduan/Github-Enhancement-Suite/.

At Khan Academy we use http://phabricator.org/ and I absolutely love it. It solves both of your named problems and a handful of others.

This is a good redesign but I wish they put more focus on developing Github Issues. The back button doesn't work (old issues randomly show) and filtering needs work (for example, how can I show issues from two milestones? how about showing issues with no comments? etc.).

Am I the only one who dislikes that they made all the fonts slightly larger? I'm working on a 1080p monitor atm and I really don't want more screen real estate taken up with no benefit.

If this is your only complaint, I think it's safe to say that they're doing pretty well overall.

Oh, absolutely, I love everything else about the change. It makes the conversation and commits/etc. much easier to follow.

I wonder why in the age of responsive design that on-page or user-settings oriented fontsize adjustment wouldn't be more prevalent.

Or the ability to have consistent tab settings that match your preference.

https://github.com/isaacs/github/issues/57

I like the larger fonts.

Interesting. I'm curious, can you share your monitor(s) setup (i.e., size, resolution, DPI scaling if any, OS, etc.) and the type of work you do please?

Just a regular Ubuntu setup on a 15.4", 1680x1050 monitor. I can read it just fine smaller, but larger is marginally nicer. Oh, and have additional styles set in my browser approximating `* { font-family: Ubuntu !important }` (it's not quite that crude a rule, but that's the gist of it)—I tried the rule for a couple weeks, tried it back the original way for a week or so and very quickly went back to forcing the font.

I'm probably best considered a full-stack web developer; but I belong to the camp that shuns body text smaller than 16px.

Thanks!

I'd like to be able to see a revision history when someone edits someone else's comment. Trust but verify. Sometimes people mess up.

I still don't understand why they allow people to edit other people's comments in the first place.

It's very nice in the context of an open-source project to be able to fix formatting and such in people's bug reports, and to be able to update the original report with a more accurate summary of the problem when needed.

The other thing I'd like to see is context on emails in a conversation thread. So if I reply to a comment you've made, it would be great to see the comment I'm replying to IN the email itself (or at the very least, the last comment on that line, if there are multiple comments).

A lot of times I'll get an email comment and have no idea what they're talking about till I click through to go back to the conversation thread

Please do others a favour and don't reply to GitHub comments from email! Many people, including myself, will edit a comment a few times after publishing it. So the comment you're replying to by email would be outdated.

I've gone so far to disable email notifications completely. Which is another win for me because I can't stand being blasted with emails all the time. It's like a never ending to do list which builds up extremely quickly.

I'm seeing a lot of overlapping text and box breaking.

Overall, I like what I'm seeing so far. The notable exception is that they removed the build status indicator for Pull Requests from the PR body and now only show the faint green check next to a commit hash. Makes determining whether a PR is good to merge a bit more difficult IMHO. Hopefully that gets fixed.

Do you guys think the headline in the example,

" Upgrade to Normalize v3 #12406 Merged mdo merged 5 commits into master from normalize_v3 about 4 hours ago "

occupy too many space in the web page?

Thank you for making the issue number large enough to read where I don't have to hunt and squint to find it!

And replies still aren't nested? Guys, multi-party conversations are not necessarily linear.

This looks so much better

Finally.

Brings a lot of clarity to what used to be a mess. Thanks for the good UI update.

I like this one!

Reply on news.ycombinator.com