Re:An epic treatise on scheduling, bug tracking, and triage
by nine_k on Thursday December 14, 2017 @01:06PM
(#15924709)
A summary is always a compromise, a judgment on which 95% of the text to leave off. Because of this, an ideal summary is hardly possible, and someone may always complain that a salient point was left out. This is not because the summary is "objectively bad", it's because the compression is lossy, and what's seen as salient differs between observers.
Re:An epic treatise on scheduling, bug tracking, and triage
by apenwarr on Thursday December 14, 2017 @10:30AM
(#15922987)
I quite liked the tl;dr, except that it left out how most of the article is "...and why". We've all heard the advice, but the article is trying to explain why the advice is true. I think an ideal summary would mention that.
Re:An epic treatise on scheduling, bug tracking, and triage
by falsedan on Thursday December 14, 2017 @11:19AM
(#15923449)
OK, I understand. Though I think the article did a terrible job of explaining why: like, why do deadlines cause engineers to become affected by Student Syndrome? It just mentions it at a superficial level, which is perfectly fine for its purposes.
edit: also thanks for writing that article, it's great.
Obviously, a summary can't be an explanation + an argument + history. It has to be the most salient points presented alone. Think about an abstract for a paper: it should tell you enough that you can understand if you should read the paper now, and enough context so that you can remember to read it later if your situation changes.
If you feel like the tl;dr doesn't pay full respects to the article, that's fine but I feel like not many readers will mind.