Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Difference between revisions of "Volunteer"

From FlightGear wiki
Jump to: navigation, search
 
m (Documentation Reviewers)
Line 56: Line 56:
  
 
==== Documentation Reviewers ====
 
==== Documentation Reviewers ====
Currently, much of the documentation that comes with FlightGear is often lacking, terse or simply inaccurate (respectively outdated) in various places due to the advances in FlightGear's code since the time when the original documentation was written. As  documentation reviewer it will 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 create 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 help files 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, while 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 familiar with the process of creating unified diff patches, but are interested in making working with your modifications very easy for the developers, check out KDiff3, a GUI frontend to the diff and patch utilities that works on several platforms (also Windows).
+
Currently, much of the documentation that comes with FlightGear is often lacking, terse or simply inaccurate (respectively outdated) in various places due to the advances in FlightGear's code since the time when the original documentation was written. As  documentation reviewer it will 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 create 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 help files 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, while 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 familiar with the process of creating unified diff patches, but are interested in making working with your modifications very easy for the developers, check out [http://kdiff3.sourceforge.net/ 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 strongly recommended to first talk about this intention 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, so please get in touch with the developers before any significant efforts!
 
If you intend to redo a major part of the current documentation it is strongly recommended to first talk about this intention 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, so please get in touch with the developers before any significant efforts!
  

Revision as of 22:47, 30 May 2006

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.


FAQ-Maintainers

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

As FlightGear is getting more and more popular and starting to attract not only developers but also actual users , it is getting obvious that many users would find it useful if there was a central bugtracker in place where people could post their bug reports or suggestions and check whether their findings have already been reported or not. While this issue has indeed been discussed multiple times on the developer mailing list in the past, the idea to actually implement a bug tracking facility at http://www.flightgear.org has so far not really been pursued. So if you also think that FlightGear could benefit from such a facility and if you could imagine to take care of the installation, configuration and possibly also the administration of a bug tracker please consider offering your services on the FlightGear developer mailing list. Primarily, it would be of interest what types of bug trackers exist, what sort of requirements they have and where they might be hosted.

Artwork Creators/Contributors

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)

HowTo Writers

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)


Documentation Reviewers

Currently, much of the documentation that comes with FlightGear is often lacking, terse or simply inaccurate (respectively outdated) in various places due to the advances in FlightGear's code since the time when the original documentation was written. As documentation reviewer it will 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 create 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 help files 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, while 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 familiar with the process of creating unified diff patches, but are interested in making working with your modifications very easy for the developers, check out 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 strongly recommended to first talk about this intention 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, so please get in touch with the developers before any significant efforts!

Screenshot Managers

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 Managers

It was recently discussed, and it is currently considered, to offer regular binary pre-releases to the FlightGear user community, these should be based on the latest CVS code and are currently planned to be released every 8-12 weeks (this may be subject to change however). This is mainly meant to allow the user community to keep up to date with the latest developments and is supposed to enable developers to recognize potential issues with development code by widening the audience for pre-release (test) code. However, primarily this is a reaction to address issues that became apparent with the official release of the 0.9.9 version, where apparently only a very small number of users actually knew of the possibility to test the pre-release binaries and even fewer people actually did use this opportunity, so that practically nobody provided any feedback to the developers, ultimately resulting in a number of critical issues going unnoticed until after the official release. As pre-release manager you should have access to a working build environment for one or several of the platforms that are supported by FlightGear, and be able to build FlightGear binaries from (CVS) source code without further assistance from the developers. If you would like to contribute in this way to the project, please make sure to volunteer by subscribing to the FlightGear Developer mailing list and offering your services there.

Pre-Release Testers

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 theFlightGear 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.