Lab Guidelines
A living document, updated as new points, or troubles:), come up.
My team is still small, and I have no interest in running a large group that operates like a paper factory. Part of the reason is time. Another is that larger teams almost inevitably bring more problems, and I have never been good at handling them, especially when they demand lengthy back-and-forth with people. Yet even in small collaborations, I have seen the same issues come up again and again over the years. Here I want to set down the most important lessons, many of them learned the hard way, as a set of shared guidelines. I believe they are essential to efficient collaboration, a healthy team, and above all, scientific integrity, even if one person’s efforts count for little against a broader culture that, at times and in places, borders on toxic.
Authorship is earned, not given as a favor
Never use a paper to do someone a favor. Anyone who hasn’t even read the paper by the submission deadline, or who contributed little or nothing to the work, should not be an author. I know that padding author lists is becoming increasingly common worldwide (see my statistics on SIGGRAPH papers here). But as researchers, we should treat it as something to be ashamed of, both for those who offer authorship and for those who accept it. It is not a norm to follow just because everyone else does it and appears to benefit. Period.
Gift authorship may pay off in the short term, for purely careerist reasons, but in the long run it harms both the authors themselves and the scientific community. Frankly, when I see a graphics paper with 8-15+ authors, my first instinct is to doubt it’s worth reading. Most graphics papers are, after all, about algorithms and computational experiments, not large-scale physics or biology projects that genuinely require many contributors. Granting authorship to people who contributed nothing but insist on being included does not only dilute your own contribution, but also signals that you don’t really take the paper seriously. And I doubt any young student wants to be supervised by someone with a long publication list who barely understands what that work is actually about.
Having been through this myself, I understand how difficult it can be for students and employees. Compromise is sometimes unavoidable, but it should never be mistaken for the norm. Remembering that matters, because as you grow more senior, you’ll have the chance to make the community fairer and better for those who follow.
Keep a running draft throughout the project.
Keep a written draft and update it as the project evolves. Writing is, of course, slower than talking face to face, but experience has taught me that it is ultimately the most efficient way to collaborate. The devil is in the details. A forty-minute meeting naturally centers on results and the broad strokes of the methodology, and with everyone arriving from a different context, there is little opportunity to get on the same page about every finer point. As a result, a small but critical detail can slip past meeting after meeting, leaving a gap that goes unnoticed until a week before the deadline, when it is simply too late to fix. Writing things down brings those details into the open early and spares everyone such “surprises”. And whatever else changes, mathematical language remains far more precise than natural language and far easier to understand than code.
A running draft is also a chance to practice writing, a skill whose importance in research is hard to overstate. LLMs can now help anyone produce a grammatically correct paper, but not necessarily a great one. What such papers often lack is a continuous, clear, and sound line of reasoning. If ideas are the bones that hold a paper upright, reasoning is its blood vessels: it carries oxygen and nutrients to every part so that each can function, and it brings the whole paper to life. Writing things down, then restructuring and revising again and again, is what keeps that circulation flowing.
Take responsibility for your code.
Every project should aim to release all of its code, ideally enough to reproduce every figure in the paper, even if that is not always necessary in practice. Whatever code you release, you are responsible for it. Triple-check that it compiles, runs, and produces the expected results, and provide clear, easy-to-use scripts for running the experiments. Most of us have, at some point, struggled with code that does something different from what the paper describes. Don’t let your work become one of those cases. Be precise, and be careful.