20,741
edits
Implementing new features for FlightGear: Difference between revisions
Jump to navigation
Jump to search
Implementing new features for FlightGear (view source)
Revision as of 20:05, 17 May 2014
, 17 May 2014→Release early, document your efforts
| Line 149: | Line 149: | ||
Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time. We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA effort is another example for this. Typically, complex ideas may very well have a shelf life of several months - often, 12-18 months. The [[Canvas]] system only took shape 18 months after it had been discussion on the FlightGear wiki for example. | Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time. We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA effort is another example for this. Typically, complex ideas may very well have a shelf life of several months - often, 12-18 months. The [[Canvas]] system only took shape 18 months after it had been discussion on the FlightGear wiki for example. | ||
Thus, sometimes good ideas may take time to materialize - and whenever timing doesn't seem to work, it's a good idea to let time work for you, by creating a corresponding wiki article to document something, and maintaining it over time. | Thus, sometimes good ideas may take time to materialize - and whenever timing doesn't seem to work, it's a good idea to let time work for you, by creating a corresponding wiki article to document something, and maintaining it over time, e.g. by adding links, quotes or references to related discussions. | ||
Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release. | Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release. | ||
If you made it to this point, you may perhaps appreciate much better why the devel community is how it is! | If you made it to this point, you may perhaps appreciate much better why the devel community is how it is! | ||