[Trumpcard]

Currently theres not an official policy, being as this has been a pretty loosely set up open source project. I've been involved with the project since pretty much it's beginning, and one of my big gripes has always been lack of commitment to ensure community changes get rolled in. As far as the decision to roll something in, thats a decision thats made by indivudual developers. I want to formalize the process a, as I really want to make sure that everyone's voice is heard, and even if you make a 1 line bugfix, if its a good fix, Im going to do my best to roll it in.

Now that I've come onboard as a developer, thats something I plan to make sure is kept up in the future. Good additions, modifications, bugfixes will be incorporated.

Questers changes are getting rolled in, I've been communicating with him via email, and once he gets his changes to a 'ready to go' spot, i'm going to merge it in. The proc support is a great change, and support for npc types will be a valuable addition for customization. Bear in mind that just because you make code changes so that all spell casters will agro each other so you can watch them fight, that doesnt mean it's going to be rolled in. Common sense should be a general rule.

I promise you though, if the code is good and clean, and it adds a useful feature to the emulator or fixes something, i'll do everything i can to roll it into the baseline, with the approval of the other developers of course.

Post full cpp files , even if you post diffs. When working out of cvs code, source lines dont always match with what you've been working on, it's easier to diff them off on this side. If you're changes are really involved, I'll send you a cvs version of the affected files and ask you make the changes to them yourself and send them back to me.. Then i'll diff them off, compile the code, verify the funcitonality and run it through some testing, and if it checks out ok, merge it into CVS.

Also, I'd like to see if anyone is interested in being a part of a TESTING team to help us track down bugs, and apply fixes. We use to have a test team, and I thought it was great. We'll need a dedicated TEST TEAM LEAD that can devote a little bit of time with the releases before we roll them out, and can run through simple test cases to ensure we dont break anything from release to release.

My general guidelines of code submissions would be this.

1) COMMENT YOUR CODE!
2) Wrap cout's you use for debugging in #ifdef DEBUG
this is a good coding practicing so when troubleshooting we can do a DEFINE DEBUG and track down errors more easily.
3) Make your changes as customizable as possible, for instance, I am against hard coded calculations, I think formulas for calculating backstab damage,critical hits, loot drop frequencies, etc, should be able to be modified through a database variable rather than having to make a change in the code and recompile. This isnt a directive, but it's nice and makes the code more flexible.

Also, come by IRC and grab ahold of one of us if you have any questions. I generally leave myself logged into IRC most of the time, so pop me a note or send me your email address and I'll make sure to reply to your question.

Everyone let me know your thoughts on this, I'd appreciate your feedback, concerns, or suggestions.