Check-In Procedures:
* The basics:
Comment everything. Document everything
* Code:
For anything bigger than a 5-line fix, run an svn diff by an administrator (dynaflash, jbrjake, or sr55) before committing. To make things easy on everybody, do these diffs from the source trunk, not a subdirectory like libhb or macosx. You don't have to bother with this if you're working in your "own" code, where you'd be the one fixing anything that broke anyway. Before changing the Mac .nib files, first email a copy of the changed .nib to dynaflash and get his approval. Also, try to link to a screenshot demonstrating the changes visually.
Making sure you're not breaking anything is *your* responsibility, not the project's. Test all potential commits with jam *and* make. In addition, at a minimum, test an encode with default settings before checking in changes. Don't check in new features unless you've got at least basic documentation written up and submitted (to jbrjake, if you don't feel like messing with the Trac Wiki yourself). If you don't know what something does, for the love of god, don't touch it!
* Collaboration:
Being granted check-in access is not carte blanche to treat the SVN like your own private sandbox. Communication is key; surprises are frowned upon. Never make unilateral design decisions -- workflow, interfaces, and default settings are collaborative efforts, and consensus is required before changing them. Unless you have at least two admins backing you, it ain't happening. The SVN trunk is for completed work. If you want to propose a new way of doing things, the proper way is to post an explanation and diffs to the dev forum and ask for opinions -- not to check it in to the trunk.
When modifying code someone else wrote (besides titer), consult with the original author whenever possible, as early in the process as possible. Similarly, when modifying a file, it is common courtesy to ask on IRC if anyone has changes planned to it. For example, if jbrjake is considering an edit to macosx/Controller.mm, he will first ask dynaflash if that's all right. This is in order to spare everyone, especially the administrators, the grief of constantly merging changes. If you're going to be checking in a slew of changes, warn people so they don't start to merge until you're complete. Never assume you are the only person working on a file.
Unfortunately, the project does not work around your schedule, rather your schedule must work around the project's. Got something cool you want to add? Make sure it fits in with the roadmap. Bug-fix releases are not the time for major interface changes or feature additions. Changing *anything* as a release-date nears will cause grumbling. If you've added a new feature to the CLI, don't try to shoe-horn it into a GUI right before a release. Avoid work that requires other work: don't add new interface elements that require custom artwork unless you've got the custom artwork already.
Remember at all times that HandBrake is a polyvalent program. It's on multiple platforms with multiple interfaces used for multiple purposes. Don't be parochial. The way you use it is not the only way to use it. The way you build it is not the only way to build it. The way you interact with it is not the only way to interact with it. Basically, there is no one true way.