From the preceding examples, we can distill a few principles of collaboration tools:
Good tools get the fundamental units of information right.
For example, with commit emails, the fundamental unit is the change (or "changeset"). When the tool failed to treat each change as a single logical entity, and instead divided it across multiple interface access points (in this case, emails), people became less inclined to inspect the change.
Getting the fundamental units right does not merely make individual tool usage better. It improves collaboration, because it gives the team members a common vocabulary for talking about the things they're working with.
When you see necessary tasks being repeatedly postponed ("I'll try to get to it this weekend … "), it's often a sign that the tools are forcing people into a higher per-task commitment level than they're comfortable with. Fix the tools and the postponements may go away.
The Contribulyzer didn't help with any of the interesting parts of evaluating a contributor's work: one still had to review the actual code changes, after all. But it did remove the uninteresting part, which was the manual search through the revision control logs for that contributor's changes. That dismaying prospect, although less work than the actual evaluation in most cases, was significant enough to be a gumption sink, in part because it's simply boring.
Removing it, and replacing it with a pleasant, lightweight interface, meant that team members no longer had ...