Get Involved

Below are details of how to get involved in the WarFoundry project and join the WarFoundry Team. There are lots of types of people who can get involved, and contributions across the board are welcome.

If you want to have a chat before joining in then please check out our forum.

The main classes of helper are:

Developers

Developer: Developers are integral to any software project, and WarFoundry has a number of different areas that require developers including API, UI and support for additional file formats. Core development is currently done in C#, but additional libraries can be written in any of the .Net languages that developers are familiar with.

Instructions on how to get set up with the required tools and source code are in our Getting Started section. Using our repository manager then developers can quickly start sharing their changes before getting them pulled into the main build.

To get a developer account on Trac, 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.

Testers/Bug Reporters

Bug Reporter: No software is ever perfect, and finding bugs isn't always something that the developers are best positioned to do. Bug reporters are an important part of the project as without them there would be no usable application for end-users. Developers are normally users and bug testers, but bug reporters aren't necessarily developers.

The most useful things that bug reporters can do are:

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

Users/Community Evangelists

User/Evangelist: An application isn't much use without users and the community that supports it. Users and community evangelists have three main roles in an open source project like WarFoundry:

  • Use the tool and make other people aware of it, what it can do and why they should use it
  • Contribute to the discussion on our forums with feature requests and end-user input
  • Create data files for your own armies and game systems

The first role will increase WarFoundry's visibility, quality and user-base, which helps everyone involved. The second ensures that WarFoundry is an army creation application with all of the features that the users need (developers may be users, but other users will have their own ideas on what is important). The final role ensures that WarFoundry has a wide base of data files that people can use.

Designers/GUI/Graphics

Designer/UI: 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.

Design contributions can be in the form of suggested designs for new features, critiques of existing features, or direct creation of a user interface that follows the best design rules. Most contributions should generally be posted in the forums, but designers/graphics contributors can get developer accounts on Trac and Subversion in the same way as developers if it is useful or necessary.

Translators

Translators: A lot of British/American/English-speaking people's projects ignore internationalisation and translations, which can cause problems for non-English speaking users. WarFoundry (currently just the UI) is designed to be translatable, so please help translate it to your local language. Translations are simple, and any translations contributed to the project will be included in the next release and made available for download. To submit a new translation, just attach it to ticket 203.

Thanks to the help of the community, WarFoundry is already available in multiple languages (currently including Western and Cyrillic alphabets) and will hopefully be available in more languages as time progresses. If you want to contribute a translation in your native language then please write it, contribute it and we'll publish it in the next release.

Documenters

Documenter: 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.