Sandbox maintenance rules

"A sandbox is a testing (or virtual) environment that isolates untested code changes and outright experimentation from the production environment or repository, in the context of software development including Web development and revision control, and by extension in web-based editing environments including wikis." - Wikipedia

1. Always document your changes.
2. Split different set of patches into different directories. It takes longer to find the set of files relating to one change if it is mixed in with 2 other patches.
3. Keep the documentation current. Try to keep some track of your reasoning too. If I read in a README that change X wasn't a good idea after all it makes the reviewer wonder why.
4. Document the status of your patch. It is important to know if this is an early test, or considered stable and workable by the author of the patch.
5. All patches should be against the latest CVS version of Drupal, and include in the README when it was last synced.
6. Don't use a sandbox for developing modules. There is a different directory structure for that.
7. If your patch is 4 lines long don't bother to put it in a sandbox. Just file an issue against the Drupal project. Small patches are quick to check and find out if they work. Sandboxes should be for more extensive changes.
8. Try to maintain patches in the sandbox. They are so much easier to check than complete files. If you are using CVS then you can use diff (cvs -H diff)
9. Please make sure your script passes the code-style.pl script. It isn't perfect, and sometimes a bit too strict, but it will ensure some level of compliance with the coding standards.