I wrote some tools a while back http://codereview.appspot.com/8706/show and http://codereview.appspot.com/9674/show that I think would be useful to the team, but which I have been unable to deploy for a variety of reasons.
I think our code review process is partly to blame. I can't fault myself for writing code that I think would be useful. I can't fault others for being skeptical until they see it working. I can't fault others for not wanting to spend time reviewing things that don't add core functionality. I can't fault others for being conservative about changes to core functionality. So as I can't fault myself or others, I think the process must be to blame. The process requires code review for all source code outside docs and demos. It requires consensus on including, but not line-by-line review for third-party code. I think our process is preventing us from recognizing ways to improve our process. To produce a quality product, we need to have useful tools, and to have confidence in those tools. But it is hard to tell whether tools are useful without trying them out on a trial basis. And it is hard to convince others to spend the time reviewing source for tools that they have no reason to believe are useful. What I would like is to be able to deploy tools that use our core code, but that are not used by it. Ideally, I would like to be able to commit tools, add them to the build system in a way that does not affect files built, and let people try them out. Then when people realize it's useful, and want to start relying on them, they could review them. Review might not need to be line-by-line, but could be that there is sufficient test coverage for them to have confidence. I think that third party is the wrong place to put these tools, since they're not third party, and because the dependency direction is wrong ; our core code depends on third party, not the other way around. I think that experimental is the wrong place, because it is not maintained, and tests there are not run on presubmit so any code put there is likely to rot. And there are no existing build system dependencies on experimental. I propose adding a directory that is a sibling of demos called ancillary. Ancillary would be for tools that can be depended on by the build system, but not by third party code. The team can use them, but makes no guarantees that they're useful to others. Candidates from ancillary that are generally useful, and that people rely on heavily can be moved into com.google.caja.tools.
