How to make Pull Requests great for informal teams

Not without reason

  • It was often unclear whether a comment was something you had to solve or just a minor improvement.
  • Discussions were hidden even though the underlying problem was not fixed yet. Creating annoying comments like "discussion x is still open".
  • Or the other way around, they were kept open when the problem was fixed, because in the end, the line commented on was not part of the fix.

Enter the new tool set

Old problems out, new problems in

  • Now discussions in which the problem was fixed are kept open, forever. Where before they were sometimes closed primarily or kept open in edge-cases, now it is completely impossible to see which discussions still need attention: they are all open.
  • Comments are not shared directly making it hard to work together. Especially on large PRs, or when heaving a tight deadline, it is great to ping-pong comments; the reviewer adding line comments, the author fixing them as they come in. However, line comments are not visible for others anymore, until you press the extra 'review changes' button and give a verdict.
  • Even worse, I've seen people forget that extra button and not knowing that their carefully crafted line comments aren't send to the author.
  • Multiple comments don't always share the same conclusion. Some comments might be positive, other might require a change. You could start two different reviews, but that's breaking your line of thought and how you go through the diff.
  • And maybe minor, but I've seen cases where the review summary is looked over by people as a separate comment needing attention.

Improvements for informal teams …

  1. Close line comments as solved, or re-open them if they are hidden.
    This allows to keep a good overview of still active discussions. It allows to close discussions if they are solved, but also if a question is answered. And if a line comment is automatically hidden, to (re-)open it if the problem isn’t solved. This way, you end up with a stream of comments which clearly show the parts needing attention.
  2. Show approval or disapproval with a normal comment.
    This allows to use the currently new review summary, from the discussion view, without having to go to the diff view.
    That might sound weird — not seeing the diff before (dis)approving. However, when you as a reviewer come back to a second time, you can already easily see the new changes from the discussion view. I often use that to check those comments, and then when back in discussion view, give my final remark.
  3. Make the combination of line comments and approval optional.
    This one is for keyboard-lovers. With the new features also came the double submit button at line comments. This means using ctrl/cmd + enter uses the new way in which a review summary is needed. Making that a choice (in the project or user settings) gives a better work-flow for people preferring old-style line comments.
And aren’t all developers keyboard lovers?

… and formal teams

--

--

--

Interaction Design Music AlsVanzelf Hilversum Sweden Intercultural Workshops OpenSpace Meditation Webdesign VirtualWorlds Everybody-Has-An-Interest-In-Education

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Lode Claassen

Lode Claassen

Interaction Design Music AlsVanzelf Hilversum Sweden Intercultural Workshops OpenSpace Meditation Webdesign VirtualWorlds Everybody-Has-An-Interest-In-Education

More from Medium

DevOps vs. Agile Methodology: Key Differences and Similarities

“Agile methodology is a contradiction in terms.”

Getting Agile Scrum right in the real world

Getting Agile Scrum right in the real world

Mental model to create a safe space for your team