Community bugtracker is up @ il2bugtracker.com

[41Sqn_Banks]

You can also stalk luthiers profile to see his activities

[mazex]

Big Kudos for putting this up... It has been needed for a long time and what is needed to get it working is voluntary admins that reject duplicates and do a quality check before accepting the bugs if they are not filled in properly with steps to reproduce, system specifications and other details needed for the developers according to rules regarding how to file bugs... Otherwise Luthier will get tired of this very fast...

I have not worked with redmine, is it possible to add custom mandatory fields like "Describe background / Steps to reproduce / Your detailed system specifications" etc?

EDIT:

Here is how to set up custom mandatory fields in Redmine:

http://www.redmine.org/projects/redm...neCustomFields

[mazex]

Originally Posted by 41Sqn_Banks

IMHO we need a "guideline" for bug reports, e.g. https://developer.mozilla.org/en/Bug_writing_guidelines

We really need quality bug reports, especially as the developers are not part of the system, i.e. they do not interact with the reporter, they only read the report.
A low quality report might be written in 1-2 minutes, but the workload for the admins or developers are increased considerably. If one wants to report a bug that he things is important he should take the time to write a high quality report.

For aircraft system this includes researching the subject and providing evidence. There are so many bug reports on aircraft systems in this forum that a simply wrong and not or bad researched.
For game bugs this requires a step by step instruction to reproduce the bug.
The reporter has to provide (depending on type of issue)
- step by step instruction to reproduce the issue
- screenshots to display the issue
- mission files/tracks to allow easier reproduction of the issue
- documents/sources to proof the issue

+ 1

[Ataros]

Originally Posted by mazex

Big Kudos for putting this up... It has been needed for a long time and what is needed to get it working is voluntary admins that reject duplicates and do a quality check before accepting the bugs if they are not filled in properly with steps to reproduce, system specifications and other details needed for the developers according to rules regarding how to file bugs... Otherwise Luthier will get tired of this very fast...

Could you become an admin please?

[Ataros]

Originally Posted by ZG15_FALKE

I would suggest one project per released version and correspondingly named. Makes it easier to keep trrack for which version/bugfix the bug or feature was reported/requested.

Then unfixed bugs have to be imported from the old project to the new one or not? It may become confusing for the devs to keep track of 3-4 projects.

Dev-heaven has a separate column for version #. Maybe they configured it somehow? https://dev-heaven.net/projects/cis/issues?query_id=30
Proposals for future are marked as NEXT GEN version.

[Strike]

Finally guys!

Excellent!

I've been promoting this type of communication myself earlier. I have a lot of good impressions from it by playing ARMA 2 and using the dev-heaven tracker

Will start registering well-documented bugs in the future. Youtube/printscreen are our friends

[SG1_Lud]

Originally Posted by Strike

Finally guys!

Excellent!

I've been promoting this type of communication myself earlier. I have a lot of good impressions from it by playing ARMA 2 and using the dev-heaven tracker

Will start registering well-documented bugs in the future. Youtube/printscreen are our friends

Long time no post mate. Really, I thought of you when I saw this and recalled how you promote the idea. But finally is here and with the devs involved. Good times.

[mazex]

Originally Posted by Ataros

Could you become an admin please?

Absolutely... We need some admin "forum" to set up the guidelines and policy's of the desired work flow for the bug reporting too.

[FG28_Kodiak]

Originally Posted by Ataros

Then unfixed bugs have to be imported from the old project to the new one or not? It may become confusing for the devs to keep track of 3-4 projects.

Dev-heaven has a separate column for version #. Maybe they configured it somehow? https://dev-heaven.net/projects/cis/issues?query_id=30
Proposals for future are marked as NEXT GEN version.

Added the column "Zielversion" may be the translation is target version.

[41Sqn_Banks]

Originally Posted by Ataros

Then unfixed bugs have to be imported from the old project to the new one or not? It may become confusing for the devs to keep track of 3-4 projects.

Dev-heaven has a separate column for version #. Maybe they configured it somehow? https://dev-heaven.net/projects/cis/issues?query_id=30
Proposals for future are marked as NEXT GEN version.

I've created a version (1.05.xxx), issues can now be assigned to this "target version", however my impression is normally used to define the version that should fix the issue. Maybe we can misuse is to define the version where the issue occurred?