Preferences

I would say that there's no such thing as a "non-blocking issue". If it's not something you want to block over, then you're saying that it's not really an issue.

This strikes me as somewhat un-pragmatic.

Non-blocking could cover everything from “wow this is kind of jank, but it’s good enough for now and let’s figure out how we fix it later” through to very minor thing like “you have a typo”.

If we blocked on everything being perfect, we’d never get anything finished. Plus, PR’s are free.

How do you organize that information so that you can actually follow up on it later?

Writing a non-blocking review feels a bit like writing to /dev/null. Good to get it out of my system but not much else.

Put it into a comment or into one of todo.txt, features.txt, ideas.txt, under docs/ or in README?
Yep, or make a ticket in whatever issue/ticket/work management system you use. Everywhere I’ve worked has always had some kind of “future stuff we’d like to do” project.
But then rather than leaving a non-blocking review, why not leave a blocking review and approve it as soon as the author responds with a link to the ticket or adds it to TODO.md?

If it's important enough to be tracked then I'd want to make sure that it's been filed properly. It's too easy to forget about such a trivial task, especially in a time crunch.

Because we’re pragmatic, and I trust my teammates to handle things like that without the need to babysit them or block them over trivial tasks?

I trust that it will get done. It is not important to me, whether it happens before the PR goes in or afterwards.

What's the point of leaving a review comment then?
Because it belongs in to the PR and only the Author knows the answer: his thoughts and rationale for the change and behaviour. Sure I could just guess, but then it's essentially poking in legacy code. The point of it being not legacy code is, that the person is still around, so he should write down his reasons, so that they are documented.
to me blocking means something about the code must change.

non blocking may be resolved if you have a strong argument for why you did it that way (most people don't, so it ends up being a code change as well).

This item has no comments currently.