2,561
edits
m (→Suggestions)  | 
				|||
| Line 91: | Line 91: | ||
These attributes could not only be easily parsed by an XML parser to provide web-based search facilities, they could even be used within FlightGear at runtime, to provide enriched status information by reading in the corresponding files and showing their contents in a dialog.  | These attributes could not only be easily parsed by an XML parser to provide web-based search facilities, they could even be used within FlightGear at runtime, to provide enriched status information by reading in the corresponding files and showing their contents in a dialog.  | ||
In the long run, it might even be an interesting option to provide optional support for three different attributes specifying filenames for these status-tags:  | |||
* bugs-filename=""  | |||
* fixme-filename=""  | |||
* todo-filename=""  | |||
That way, it would be possible for contributors to easily provide very detailed information about the development status of individual components or features, simply by dropping a corresponding file into the aircraft tarball, possibly using a standard-location/folder such as "meta-info" within the aircraft's folder.  | |||
Likewise, users noticing new issues could easily augment said files and send them to the maintainer to have them committed to HEAD, so that future users can first check out this information before possibly reporting a duplicate issue/feature request.  | |||
While it may seem unnecessary to provide this sort of information-collecting infrastructure to aircraft authors and their contributors, it would probably help aircraft development status become more self-documenting and aircraft-development itself become more self-contained, given that key information would be collected in one central place (the repository) and aircraft-specific issues/ideas could be easily reported and checked for by new contributors.  | |||
In the long run  | |||
=== A Flexible Approach ===  | === A Flexible Approach ===  | ||
edits