Get Involved

Below are details of how to get involved in the WarFoundry project. There are lots of types of people who can get involved, and 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
• Test the tool out with their favourite game system

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 the default text-based file format can also be created by hand.

Details of the standard WarFoundry file format are now available on the Wiki. Files can be created with a text editor and a Zip file creator (e.g. WinZip, WinRAR, File Roller, or similar applications).

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 this site 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 three main jobs for a Documenter - user docs, developer docs and requirements. 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. Requirement documentation is documentation from a user's point of view that helps developers know what features the users want/need.

Once we approach our first stable release then contributions of user guides could be put together in the ​forums or this wiki before being copied to the ​main website. Members of the "Documenter" group can contribute user directly to the wiki, and anyone is welcome to be a documenter.

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 can get developer accounts on Trac and Subversion if useful and necessary.