• Skip to site navigation
• Skip to sidebar
• Skip to content
• Skip to footer

Project Policies

This page describes various policies and guidelines for the Wesnoth-UMC-Dev project. The policies described herein should 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. This includes:
  • WML;
  • scripts or snippets for the Lua interpreter;
  • formula AI files;
  • UMC maintainance scripts; and
  • audio or image files in open, patent-free formats.
  This excludes platform-dependent cruft such as Thumbs.db files (Windows shell thumbnail cache), .raw files and closed-format image and audio files. PSDs are a special (permitted) exception since a free software tool, the GIMP, is mostly compatible with the format.
• Artwork and content: You must abide by the SourceForge terms of service forbidding copyright violations and material which would be considered obscene, slanderous, or otherwise in violation of the law where the servers are hosted (California, USA). Use your common sense; if in doubt, ask an administrator before uploading.
• Object-code and executable binary programs: these are not allowed, since they:
  1. are of limited usefulness;
  2. are generally larger than the parent source-code program; and
  3. source code available in the same repository is required to comply with the terms of the GPL.
• 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 #wesnoth-umc-dev channel on the Freenode network [webchat | client]. 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.