Get Involved

Below are details of how to get involved in the WarFoundry project. There are a number of different groups of people who can get involved, but contributions across the board are welcome.

Users/Bug Reporters

No software is ever perfect, and no software ever has as many users as it could have. Users are an important part of the project as without them there would be no end-users. Developers are normally users, but users aren't necessarily developers.

The most useful things that users can do are:

• Use the tool and make other people aware of it
• Contribute to the discussion on ​our forums
• Write bug reports or feature requests for things that aren't working or need improving
• Investigate existing bug reports and see if they can re-create them to provide additional information to the ticket

If you want to contribute bug report/feature tickets then you'll need to register an account on this site.

File Creators

File Creators are closer to developers, but don't need to work with the source code. Rollcall previously had ​lots of ADF files, but WarFoundry will start off with no native files. Plans are afoot to build file editor apps, but any text-based file can also be created by hand.

We don't currently have documentation of the file format, or even a finalised format, but when we do then we'll need people to create race definitions.

Developers

Instructions on how to get set up with the required tools and source code are in our Getting Started section, but to contribute changes back to the project you need a Subversion account and additional developer permissions on Trac.

To get a developer account, sign up on Trac and then contact IBBoard (either ​through the forums or ​his website) to get the account promoted to a "developer" account and a Subversion account created. Once you set up your Subversion repositories with a username and password you will be able to commit to both the WarFoundry and IBBoard utils repositories.

Documenters

There are two main parts of documentation - user and developer. User documentation helps people get started with the tool or use advanced features, while developer documentation helps people understand the API so that they can get to grips with it or write plugins.

Once we approach our first stable release then contributions of user guides could be put together in the ​forums before being copied to the main website.

Most of the developer documentation should be written as the developer's write the API (documenting what public methods do so that they can be tested and so that they have a defined contract of what they will do given certain inputs). A large enough project is always difficult to get started with though, so introductory tutorials adding small features or step-by-step guides to creating plugins may prove useful.

Designers/GUI/Graphics

A lot of open source applications can be functionally great but have a poor user interface and it can be a poor user interface over a great program that puts people off using it. The split between a back-end API library and front-end UIs makes creating new interfaces easier, but input on existing interfaces, new icons and other graphical feedback would also be appreciated. Any contributions should generally be posted in the ​forums, but designers/graphics contributors may get developer accounts on Trac and Subversion if useful and necessary.