OpenBOR Development Policy

[Damon Caskey]

The following has come about as a result of past experience coupled with discussion at length among the Lead Developers of OpenBOR (SX and Damon Caskey).

These policies are to be followed by any and all members with access to the SVN. Failure to do so will result in the loss of all write access to the SVN, and may incur forum infractions as well.

• Log Chat
• Functionality Removal
• Feature Creep
• Modder Control
• Collaboration
• Alternate SVNs & Unofficial Offshoots
• Backward Compatibility

[Damon Caskey]

The SVN is not a forum. It is a subversion repository and should remain absolutely professional at all times. When adding notes, be brief and concise. Provide an overview of any changes made, their main purpose, and if needed (such as for a new feature) basic documentation. Do not use silly colloquialisms like "Moar", "l33t", and so on. 

Do not criticize other coders. As per the overall forum policy, this sort of behavior will not be tolerated in any capacity. It is one thing to disagree with someone's methods, it is quite another to disparage or insult them. Aside from being unprofessional and just plain rude, it's a solid bet whatever you are dismissing was done that way for a very good reason.

Also do not use the SVN for discussion or debate in general. That sort of thing belongs on the forum.

[Damon Caskey]

Do not remove any functionality from the engine. No exceptions. No matter how superfluous or wasteful you think something is, someone else out there is certain to be making good use of it.

You are of course free to optimize and substitute, so long as the new version retains all the capability of whatever it replaces.

[Damon Caskey]

This is fairly subjective, but in general avoid adding pet rocks to the engine. We all want the engine to be as powerful as possible, but also efficient. A mishmash of overlapping features that only a Cray could handle won't help anyone.

When you do add a new function or feature, make it as open ended and future proof as possible. For example, you would like to specify lethal or nonlethal attack boxes. Instead of adding a static lethal/nonlethal sub property to attacks and shoehorning the engine's behavior, why not add a user definable meta parameter and use it to script the results? This way you gain the desired functionality and other creators can make use of it for a variety of other needs.

Also, do not make major modifications to the engine for the sake of a single module, yours or otherwise. Modder creativity is the law, but in as much as they can try whatever they want... not that we as developers are obligated to make it work for them at the cost of expensive code bloat or other modder's projects.

[Damon Caskey]

A Modder's creativity is the law. Do not add code that overrides any open parameter or forces log warnings by default. An example would be blocking negative values for jumpheight or not allowing landframe to exceed an animation's frame count.

OpenBOR is a user content reliant application. As with similar apps, sooner or later someone out there will think up a way to use the engine's facets in a way you didn't. Let them.

This does not preclude additions like sanity checks when the parameter performs its intended function, debug modes, voluntary validation, logging the reason when a shutdown occurs and so on. Common sense applies.

One last note, a modder is free to try whatever they wish. This policy does not mean we are obligated to "fix" the engine when their trick doesn't work. See Feature Creep.

[Damon Caskey]

Check your ego at the door. This is an open source application.

If you don't want your code touched from now till doomsday, go somewhere else. If you think the reason you were told "no" by a lead dev or had commits rolled back was because someone got jealous of your leet skillz, you have no place here at all.

Conversely, do not edit another user's code just because you don't like it. The SVN is not your geek arena. Take that stuff to the forum (and best keep it civil when you do). Any subversion wars will result in both parties loosing SVN access.

Lastly, we will all make mistakes. If you see an obvious error, fix it, point it out and politely explain what the issue was. Trying to make another member look or feel stupid will be treated the same as any other flame bait.

[Damon Caskey]

Many developers choose to keep an unofficial copy of the engine source for their own purposes. This is technically permissible when the license is adhered to and there is little we could do to stop such actions anyway.

Note however, that alternate versions of the engine will not be supported. If you choose to go out on a limb and find modules will not work with your branch, it is your problem. This also applies to modders who feel compelled to use unofficial or outdated engine distributions.

Also, if an alternate subversion is discovered it will be held to the same standards as the official source. Any professionalism violations found will be treated as if they were committed in our SVN. No, we can't tell you what to do with "your stuff". But we can prevent you from having further access to ours if we find you dragging our image through the mud or otherwise using an alternate source to get away with behavior that wouldn't fly here.

[Damon Caskey]

Backward compatibility is always a general priority. Do not break any form of backward compatibility without first discussing with the Lead Devs. Review of a backward compatibility request will be handed on the following criteria:

Gameplay: For in game behavior, there can be no exceptions. Every module must play correctly on the latest engine except in the most extreme cases (to be reviewed case by case).

Interface: For menus and interface, backward compatibility is desired, but not an absolute requirement, except where it interferes with a module's functionality. A change in the options list is probably not going to affect anything, but reversing character select order or suddenly moving a menu to the top left screen corner is probably going to cause a big mess.

Unfinished Mods And Flux Features: Except in certain extreme cases, modules in development generally do not receive backward compatibility priority. This also holds true for use of features that are still in development or marked as subject to change.

Other: Any default behavior change that does not directly affect the game or user experience will most likely be approved, so long as it is tested thoroughly.