This page attempts to document the <buzzword>norms</buzzword> of the MegaMek developers. First and foremost, this is to help people who are new to the team figure out what the other developers on the team expect of them. It also helps people who are thinking about joining find out what would be expected from them if they choose to join our motley band. We’re a pretty informal bunch, as you’ll soon discover, and our rules are pretty much the “don’t screw up” variety. That, and “make sure everyone knows when you made a change.”

• Pretty much anybody is allowed to be a developer, after you’ve proven that you have the slightest programming clue.
• Submission of patches or bug fixes is the best way to prove cluefullness.
• There are plenty of non-coding tasks to be performed, so please volunteer if you think you can help out in some other way.
• Members of the team have access to a Developers Forum. The general public doesn’t. We use it to talk about proposed changes, coordinate between ourselves, and ask questions.
• Public airing of posts from the forum is discouraged (but not prohibited).Especially features that will be released in future versions.
• Until a feature is coded, we can’t be certain that it will be released at a certain date, and we’d rather be mysterious than overpromise.
• When coding, try to adhere to the format style already in place. If you’re not certain what that means, ask on the Open Forum. The biggest thing to be aware of is that we use spaces instead of tabs for our indents, and we use 4 space indents.
• All development is commited to CVS. Check out the SourceForge site documentation on CVS if you’ve never used it before. If you still have questions, contact a project admin or post in the Developers Forum.
• When CVS is committing changes, it automagically converts your local file format (e.g. DOS text file) to a neutral (i.e. *nix) format. If you check a file out on a Windows box, copy it to a *nix (or Mac) box, and check it back in, you’ll screw up the format. Nothing fatal, but it is annoying, and you should be careful when copying between different operating systems.
• Don’t commit a change to CVS until you’ve made a good faith effort to debug it.
• Don’t worry overmuch about finding all bugs before you commit. We’re human, and this is a hobby.
• Every time you make a change, document it in history.txt and in the “commit message”. This lets other developers and the community at large know what you’ve just done.
• The first person to make a change after a weekly release should bump the version in history.txt and MegaMek.java. Be sure to include “-dev” at the end of the version number so everyone can distinguish a CVS build from a snapshot build.
• After that first update, list new comments under the existing comments for the new build number. That is, comments are ordered descending by build number, ascending by time.
• Typically, suvarov454 will release a development snapshot once a week. I bet that he’d be willing to turn over the task to a volunteer.
• If you can’t think of any feature to code up, check out the Bug or Feature Request tracker. Work on the higher priority tasks first, unless you don’t feel like it.
• If you’re working on a Bug or Feature Request, please Assign yourself to it. If you can’t Assign yourself to a Bug or Feature Request, contact a project admin or post in the Developer’s Forum.
• If you’ve got a radical change to the code, consider submitting it to the Patch Tracker instead of committing it to CVS. That way other developers can try out your change, without risking the mainline code.
• Consider using the Task Tracker to handle multi-step code. It reallyboosts our standing in the SourceForge Most Active List. Don’t go crazy with it, however.
• Above all else, have fun! This is coding a game for a hobby.

2 Responses to “Developer’s Guide”

1. Robert says:

   November 27, 2009 at 6:37 pm

   I have MegaMek and was wondering in the Latest Dev release there is the annoying window of “Incoming Messages” that goes up and down while I play the game, I find it VERY annoying and was wondering how do I make it not show up?
2. beerockxs says:

   November 28, 2009 at 5:59 pm

   In the next release, there will be an option in the advanced client settings that changes the chatbox so that it only scrolls up and down when you click the maximize/minimize button, and not automatically.