Gorilla thanks. U kinda exlained what's needed.. My vision it to "filter" the results and then have a direction of things to fix from user reports...
Users are our best friends.. who can complain to their hearts content.. The issue now is that we need to "register" and recongise all the failures, so they can be identified and fixed.. I love the idea of 2 weeks.. as that is a recognision of problem and solution... Only thing is that whats REALYY important is the /data/ and this even in git yet anywhere. ?? The bug reports ie cusomter satisfaction and FDS so not mix, they are two seperate mixtures... pete George Patterson wrote: > On Thu, Oct 1, 2009 at 2:25 AM, Curtis Olson <curtol...@gmail.com> wrote: > >> I agree that a bug tracking system is a good thing. My thoughts & hopes are >> that once we finalized what we were doing with our eventual move away from >> CVS, We would move our code to a system that offers a number of developer >> features including an integrated bug tracker. Google does offer a nice >> system, but long term, it would be nice to just use the bug tracker >> associated with our project, rather than setup a completely new project and >> only use the bug tracker out of it. >> >> Curt. >> >> >> > > I totally agree that an issue tracking system is required. > > >From the short run that Pete Morgan and a couple of others have had a > couple of things come to mind. > > - Proforma reports with at least the following information > - Steps required to reproduce the bug > - Operating System and version > - Which version of FlightGear were you using? > > - The moderators need to be able to close tickets that are incomplete > and the submitter is out of communication for an extended period of > time. I'd say one fortnight, though that might be too long/short. > > - The idea where a user that submitted a bug report can also accept it > as a bug is broken (unless the tickets are split into user issues and > bugs. > > As an example a user reports an issue as "Flightgear stalls with lots > of NaN messages being display on console at TBPB". The Bug could be > "NaN messages are displayed on console due to bad input data". If you > have other related issues, then you link the issue to the Bug ticket. > This cuts down the redundant tickets that a developer needs to wade > though. > > > This is fast getting into ITIL land. I am familiar with Atlassian Jira > for incident and problem management but it's an overkill for > FlightGear base. > > What's the url for the ticketing system we have? > > Regards > > > George > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
