Volunteer: Difference between revisions

m
No edit summary
 
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!