Talk:Feature Requests / Proposals / Ideas

From FlightGear wiki
Jump to navigation Jump to search

Related Discussions

Cleanup

This article has been marked as requiring cleanup, and I agree. I think one simple way to clean up this page would be to provide a (sortable) table template, so that all items can be put into a corresponding table. Suggested columns would be:

  • description
  • required skills (C++, OpenGL, Modeling etc)
  • component (FDM, GUI, SOUND etc)
  • estimated time to complete (complexity)
  • popularity rank

using a dedicated tracker

While this whole section looks definitely useful, I would seriously consider implementing it via some sort of separate bug tracker, eventually this should have many advantages. For example, upcoming versions of bugzilla are planned to provide support for automatic roadmap creation based on requests. Likewise, you could actually group requests into appropriate categories, possibly based on Flightgear components/subsystems.

What do you guys think?


more stuff from the archives:

Controversy regarding proposal to use the SF.net tracker

Quote:

 Please note: We now have a a tracker on SourceForge at [1]. 
 Please list your bug/feature request/enhancement/idea on SourceForge as well as here.

Well, personally I am not sure if adding such advice is a particularly good idea at this time:

  • this tracker has been around for ~8 years, so far it's always been pretty much ignored - by developers and contributors, as well as by most users
  • there are certain restrictions when using SF.net resources (i.e. volunteer maintainers would also require sourceforge accounts, and they would explicitly need to be given the corresponding privileges by the project administrator)
  • the SF.net tracker is not the most convenient tool to use
  • there are meanwhile several other, more feature-rich trackers available, which would also allow for regular backups to be easily done and store offsite
  • various other people have in the past proposed to set up trackers, even to maintain and administrate them: to no avail!
  • some people even went as far as setting up complete systems, only to see them being rejected in the end [2]

and most importantly:

  • afaIk: developers never officially agreed to use a tracker (and this tracker in particular) so far [3]
  • in fact, people have been previously advised explicitly by core developers, not to use this particular tracker [4]

And the latter two points are actually the most important ones: whatever clever system people may set up,as long as there is no official consensus regarding the use of one particular system (among all developers), this is going to be a fruitless effort.

This whole thing would only be likely to work, once the key people behind the project (i.e.long-term developers and contributors) decide to actually use a tracker system (and also WHICH one).

Until this decision has been made and clearly stated, it would not be particularly wise to start using any sort of additional tracker system (however poor this one might actually be).

Thus, I would refrain from encouraging people to possibly spend lots of time on migrating the current list of issues from the wiki to the SF.net tracker, or even just using other trackers at all.

Apart from that, the fact that the SF.net tracker is available, doesn't change the static nature of the wiki:

 Also, as this is a static page and no searchable bug tracking system, no longer true - see
 above re SourceForge tracker [...]

Don't get me wrong, using a tracker is definitively a good idea and needed, however some decision making needs to take place before that can happen.--MILSTD 09:08, 19 March 2008 (EDT)