Check-In Procedures:

* Comment everything

* Document everything

* For anything bigger than a 1-line fix, run an svn diff by an administrator (dynaflash, jbrjake, or sr55) before committing

* Before changing the Mac .nib files, first email a copy of the changed .nib to dynaflash and get his approval

* When modifying code someone else wrote (besides titer), consult with the original author whenever possible

* When proposing medium-to-large changes, post an explanation and diffs to the dev forum

* Test all potential commits with jam *and* make

* Don't check in new features unless you've got at least basic documentation written up and submitted to jbrjake

* At a minimum, test an encode with default settings

* Making sure you're not breaking anything is *your* responsibility, not the project's

* Never make unilateral design decisions. Workflow, interfaces, and default settings are collaborative efforts. Consensus is required before changing them. Unless you have at least two admins backing you, it ain't happening.

* If you don't know what something does, for the love of god, don't touch it!

* 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 self-centered. 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. When you assume there is, you piss off everyone else with your parochialism.

* Remember that the project does not work around your schedule, 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 is frowned-upon. Avoid work that requires other work. If you've added a new feature to the CLI, don't try to shoe-horn it into a GUI right before a release. Don't add new interface elements that require custom artwork unless you've got the custom artwork already.

* The SVN trunk is for completed work. If you want to propose a new way of doing things, the proper way is to post to the dev forum and ask for opinions -- not to check it in to the trunk.

* Being granted check-in access is not carte blanche to treat the SVN like your own private sandbox.

* Before 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.