This question got sparked by a recent discussion in the 2nd Monitor about this question: Golang Map-Reduce Master - Channels.
The problem is: How much context is needed to actually review the code in the question? How much should the reviewer assume about functions/types/object states which are referred to in the code but not included in the question itself?
In this case, it could be looked up on GitHub, because the code in the question was part of a larger project. Should this be required?
Also, the correctness of the implementation depended heavily on object state being setup correctly (otherwise it would deadlock). However, the setup code isn't included in the question. Without any mention by the OP other than "[it] passes the tests", how far should the reviewer go in assuming that everything got setup correctly? (Especially if the code could be called from anywhere, i. e. setup isn't guaranteed to be done.)
EDIT: After there had been some uncertainty in the comments, I'd like to clarify my problem. I'm mostly concerned about major dependencies.
These might be (heavy) dependencies on (at least for the reviewer) unavailable code, especially if there is some non-obvious communication going on (e.g. setting some globals that then get referenced later on) or some of the actual core logic happens there.
This could also be unstated pre- or post-conditions that would otherwise be hard to infer just from the code.
We as programmers and reviewers rely a lot on having as much context available as possible. And while it isn't required to have the whole context available to review a piece of code, a substantial fraction is. Sometimes some of that context can be inferred or some educated guesses can be made, but where is the line between not enough and just enough available information?