Difference between revisions of "Volunteer"
m (→Bug Tracker Administrators: bug-tracker update)
|Line 6:||Line 6:|
==== Bug Tracker Administrators ====
==== Bug Tracker Administrators ====
reported at http://.flightgear. to of the the list, would bug .
==== Artwork Creators/Contributors ====
==== Artwork Creators/Contributors ====
Revision as of 05:54, 13 February 2010
This page is dedicated to showing that enthusiastic FlightGear users do not necessarily have to be familiar with C/C++ or 3D modelling in order to be able to make a meaningful contribution to the FlightGear project. There is a whole variety of interesting possiblities to make very gratifying contributions to FlightGear without having to be a developer. Often, work in such non-development related areas will at least be as appreciated by other users as are contributions by developers, simply because it is in the nature of non-development related contributions that they will specifically appeal to non-developers/users. So, if you would like to help the FlightGear project improve, please take a look at the following opportunities and feel free to make suggestions for new ones.
The FlightGear project is currently looking for people who are willing to maintain the FAQ, if you you would like to get involved, please subscribe to the FlightGear Developers Mailing list in order to discuss the details.
Bug Tracker Administrators
Bugs are currently being reported at this tracker. Feel free to contact one of the project owners to be added to the member list, if you would like to add a bug (or two).
FlightGear itself would not be possible without the contribution of various types of artwork, i.e. often aircraft developers have to use different resources to accomplish the goal of realistically modelling a particular aircraft. Hence, it is essential to contribute resources such as photographs, images, sounds (to be continued)
Scenery Model Creators
The FlightGear project maintains a steadily growing repository of 3D models for adding some eye-candy to the Scenery. The World has always enough room left for your contribution. Please take the time to investigate what's already there and enjoy populating your favourite area.
Various parts of FlightGear are currently not yet sufficiently documented, also available documentation is often not really suitable to be used by non-developers. This results in users being unaware of the wide range of features and possibilities that FlightGear supports already. As "HowTo writer" you should be able to document your own experiences with FlightGear in a clear and concise style, so that others can easily follow your instructions on order to make use of FlightGear's less known features. HowTo guides do not need to be very comprehensive, they shall only serve the purpose of providing users with easy to follow instructions about how to set up their version of FlightGear.
Topics that could currently use some HowTos are:
- configuring FlightGear for multi screen setups, where a single "master" machine running FlightGear is connected to an arbitrary amount of "slaves" that can be set up to display different views, most of the required information can be obtained from the mailing list archives by searching for "multi", "screen", "head", "slave", "master", "display","frustrum" (or any combination of these) 
- activating and using AI scenarios (the nimitz scenario is a good example)
- using basic radio navigation equipment in FlightGear
- using the GUI autopilot
- using the KAP140 autopilot
- using the KLN89 GPS (requires latest CVS code)
- interfacing FlightGear to real hardware (basically, how to use the property tree network interfaces)
- creating custom AI scenarios
- interfacing FlightGear with other software (mainly atlas,opencockpits - property tree usage again)
- creating and modifying scenery using fgsd
- creating and adding custom views
- setting up additional aircraft panels
- adding arbitrary instruments from the base package to existing aircraft panels
- using the nasal scripting language to add custom logics to FlightGear
- adding custom menu items to the FlightGear menubar
- creating and using XML based GUI dialogs
- using multiplayer features from fgrun
- creating customized joystick configuration files
- using and creating XML protocols
- configuring and using AI ATC
- creating and adding support for new textures to FlightGear
- translating FlightGear
- modifying and creating new sound effects for aircraft
- helicopter flying with FlightGear
- creating custom FDMs
- using the replay system
- recording FlightGear videos
- using fgrun
- using fgsd
- using taxidraw
- modifying the airports database
- modifying the navaid database
- using terraysnc
- converting 3D models from other flight simulators for use with FlightGear
- installing nvidia drivers under linux (misc mailing list discussions recently)
As already stated on the Wiki main page, FlightGear comes with a set of illustrated documentation, notably "The Manual". This piece of documentation aims at being printed onto paper and being read as a reference while you're exploring FlightGear - or simply taken with you on a long trip. If you are a skilled writer and a little bit familiar with LaTex, please take the time to dig into the PDF or HTML version. Instructions on how to get the source code are here. It lies in the nature of FlightGear development that The Manual is always a bit behind current development. We invite you to pick information from a) your personal experience with FlightGear, b) the available README's in the FlightGear source tree or the Base Package or c) the Wiki and merge these into an appealing shape for The Manual. Turn your head to the FlightGear developers' mailing list and you'll find someone to talk about how to improve The Manual.
Currently, some of the other documentation that comes with FlightGear is lacking, terse or simply inaccurate (outdated) in various places due to the advances in FlightGear's code since the time when the original documentation was written. This state is not improved by people's tendency to create new documents instead of maintaining what already exists. As a documentation editor/reviewer, it would be your task to check the current documentation and identify areas for improvement. Preferably you should also be able to directly make corresponding suggestions for augmentations, or even write new help documents altogether (possibly based on evaluating recent mailing list discussions). You would be expected to thoroughly check the documentation folder ($FG_ROOT/Docs) and review all relevant documentation for obvious shortcomings or mistakes, smaller corrections shall be sent by email to the developer mailing list, preferably in unified diff format (for patch to work). Alternatively, small text files can also be sent directly to the mailing list, more complex modifications should be only made available by uploading them to a webpage and linking to the corresponding files from your emails. If you are not now familiar with the process of creating unified diff patches, but would like to make it easier for the developers to work with your changes, please consider trying KDiff3, a GUI frontend to the diff and patch utilities that works on several platforms (also Windows). If you intend to redo a major part of the current documentation, it is recommended that you first discuss this with the developers, to ensure that you do not end up documenting code that may also be subject to major changes or even removal altogether. Please contact the developers before launching into a major documentation effort.
In order to illustrate FlightGear's impressive and advancing capabilities it was recently suggested (and agreed) to conduct monthly screenshot competitions where users are encouraged to submit their best FlightGear screenshots, so that the very best screenshots will be posted on the webpage for one month. Participants are expected to make their submissions at the end of each month, submissions should not be directly sent to the user mailing list as attachments, rather participants are expected to upload their screenshots to some free webspace and send mails containing links to their screenshots to the FlightGear User mailing list. It will be the decision of the screenshot managers to determine which screenshots shall win the monthly competition and are thus uploaded to www.flightgear.org
Pre-release testers will be regularly offered the opportunity to test development code without having to build the corresponding binaries themselves, it will be expected of you to provide feedback about your experiences with experimental code to the developers, you should be able to provide details about your hardware and software setup, as well as being able to follow developer requests to track down any potential issues. You should also be willing to test run all aircraft that are by default included in FlightGear's base package on the platforms you have access to in order to ensure that all default aircraft are working properly. By directly providing feedback about your experiences with FlightGear's development code, you will become a crucial part of the development process and you will basically serve as quality control for FlightGear, your experiences will determine whether FlightGear's development code is ready for a next official release or not. If you are willing to volunteer in this way to the FlightGear project, please consider subscribing to the FlightGear announcements mailing list, where future pre-releases are likely to be announced in order to attract a greater number of potential pre-release testers.
Note: If you are interested in actually doing development for FlightGear, make sure to check out the Developer section.