Confluence is bulky. Why bulk it up more with versioning code in flux with it. Subversion does this better.

As we bounce around ideas in this volatile stage we may make several changes. And
for each change we have to maintain it in two places. Furthermore there's going to be a perpetual synchronization problem.

What about this instead?

(1) comment code in the code and discuss things on the mailing list
(2) stabilize interfaces after several passes then commit to them(3) remove the code from confluence and just reference the code in subversion(4) remove @todo comments talking about design issues and use them to
compose the design documentation explaining these choices made(5) use extra energy and time to organize better the developer documentation on this and give synopsis using our new Posidon tool to show a clear picture

If you really want to duplicate this code in confluence then I'll do that our of courtesy. However I'm hoping you think twice about it and save me the trouble.

Also if our developer documentation is riddled with scratch pad notes and contains
code duplicated in the repository but out of sync who's going to want to deal with filtering that volume of information. On this track we're going to make the developer documentation ineffective.

Thanks,Alex

P.S. I have been noticing that the quality of the developer documentation is dropping because
we use it as a scratch pad which is fine but we never really cleanup. Or we mix the essential concepts in with lots of irrelevant notes. So this bypasses the purpose of transferring knowledgequickly and efficiently to our team.

I think it's better to add comment this way than modifying the code onsvn, if they are general comments. For code comments, or modification,the best would be to do it directly on code, and commit the code.