Implementing new features for FlightGear: Difference between revisions

Jump to navigation Jump to search
m
mNo edit summary
Line 93: Line 93:
== Release early, document your efforts ==
== Release early, document your efforts ==


Use the forum and/or the wiki as a platform to show people what you are doing and how you are progressing. People need to be aware of things before they can help you, and you may get useful pointers just at the expense of posting your current vexing problem in the forum.
Use the forum and/or the wiki as a platform to show people what you are doing and how you are progressing. People need to be aware of things before they can help you, and you may get useful pointers just at the expense of posting your current vexing problem in the forum. It is also always a good idea to do a forum/devel list search to check the archives for related discussions that took place in the past, this should give you a good idea on discussed approaches, but also people involved in these discussions (and if they're still around or not).
 
While the forum and the devel mailing list are great places for discussions, there are sometimes topics that have been discussed at great lengths, this includes topics like multiplayer improvements or even combat support for example.
 
For such popular discussions, there are often 5-10 threads per year on the list/forum with typically dozens of responses. Another popular debate is better multi-threading support, but also scenery improvements.
 
Accordingly, given the popularity of these topics, there are typically hundreds (or even thousands!) of postings and statements that have been made over the years.
 
Often, with little -if anything- materializing from such debates directly, no matter how good the discussed ideas were. Postings may contain good suggestions, useful feedback, but also lots of controversial arguments.
And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved.
 
Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time.
 
'''Time''' really being the keyword here - some topics are not about a single isolated feature that can simply be implemented by some random developer, those are often large-scale architectural changes, or even proposals to change the project's philosophy ([[Release Plan]]) or some of its infrastructure (e.g. the [[FlightGear Build Server]]). Thus, these topics are often not about people disagreeing that something needs to be done, but the suggestion really is a long-term item, that needs to be tackled over time - typically many months, often several years.
 
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.


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!

Navigation menu