Application & Policies

Any enthusiast Wesnoth add-on author is eligible for getting their own add-on or add-ons into the Wesnoth-UMC-Dev SVN repository. Although the project’s original goal was to provide a mechanism for syncing the work of many authors on a single add-on, nowadays we are also hosting add-ons maintained by single individuals

By add-on, it is understood that we may refer to Wesnoth campaigns, scenarios, eras, map packs, resource packages for other authors, etcetera.

The basic steps for applying are:

1. Get a working SourceForge.net account;
2. Register an account in the Wesnoth.org official forum board if you haven’t done so already;
3. Contact a Wesnoth-UMC-Dev staff member by forum PM or email. In your application, you must provide:
   1. Your acceptance of the project policies, as detailed later in this page;
   2. Your SF.net account name so you can be added to the project’s member list;
   3. An initial copy of your add-on so we can audit and commit it, whenever possible; and
   4. The game engine versions your add-on is intended for in order to create an initial dir for it in the correct location of the repository.

The policies described in the remainder of this page must not be considered a replacement for SourceForge.net’s Terms of Service, but an addition instead.

Content Policies

• All content allowed inside the repository must be distributable, modifiable and reusable under a license conforming to the Open Source Definition; to reduce complexity, we recommend the GNU General Public License, versions 2 or 3. In the case of music, sounds, graphics and other binary resource files, as an special exception to the GNU GPL, the “source code” of those files is considered to be the files themselves.
• This is not a general-purpose repository. Only material necessary and relevant for UMC development is allowed.
• Artwork and content: You must abide by SourceForge.net’s terms of service, forbidding copyright violations and material which would be considered obscene, slanderous, or otherwise in violation of the law. Use your common sense; if in doubt, ask an administrator before uploading.
• Vandalism, cracking tools, or code deliberately designed to exploit security flaws in Wesnoth or other software are strictly prohibited and will be considered cause to immediately revoke your repository write access.

Workflow Policies

• Technically, developers of one add-on are free to modify other add-ons’ code. However, as a matter of respect and politeness, you should always ask before touching other people’s work to do anything more than repairing obvious errors. Use your common sense, remember that all modifications are tracked, and that defacing another’s work could get you kicked off.
• The repository administrators and half-administrators may from time to time run automated tools to keep Subversion properties adjusted to match your files, and to ensure your add-on does not suffer from bugs that may inconvenience other authors, artists or translators.
• Ocassionally, content-altering tools such as wmllint, wmlindent, and wesnoth-optipng may be applied on your content if the add-on is left abandoned or other strong reason for doing it appears. This is normal and intended to maintain a high level of code quality and readability. If you apply them yourself, we won’t have to surprise and possibly inconvenience you by doing it.
• Campaigns, eras, and other modules must use the new-style organization in which all files for a campaign named “Foo bar” live under a directory named Foo_bar with the main WML file as _main.cfg directly beneath it. The old style in which the main WML file would be named Foo_bar.cfg and be at the same level as the campaign directory is deprecated; if you submit an add-on in this form, it will be changed to the new style to keep the corresponding major tree clean.
• You should not check the .pbl password file for your add-on into the repository, as this exposes your password to anyone with read access and could result in your content being vandalized on the add-on server. Remember that removing a file from a Subversion repository does not erase its history. Anyone may access previous revisions of a file or directory using the ViewVC web interface.

Workflow Guidelines

• We recommend that all developers subscribe to our commit mailing list, wesnoth-umc-dev-commits. See the project page, “Mailing Lists” menu, for information.
• We also recommend that all developers regularly monitor the project’s IRC channel. Developers not joining the channel may miss important notices and announcements. It is also a great way to get familiarized with other fellow developers from Wesnoth-UMC-Dev and mainline, and the project admins and half-admins, or get quick help from them.