Community bugtracker is up @ il2bugtracker.com

[ZG15_FALKE]

I suggest we have a project for every release.

Within on of those projects the incoming bug reports should be checked for being provided with the necessary information.
Only after being checked and being complete in terms of necessary information provided, a bug report should then be assigned to Luthier for nearer observation and feedback requests or status info concerning this bug report.

Otherwise dev team gets spammed and will soon loose interest.
Providing all necessary information for a bug report should be done by the community to get some workload impact off the devs shoulders.

Maby this is a topic which is to be talked about e.g. via TS / Skype?!

[41Sqn_Banks]

Originally Posted by ZG15_FALKE

I suggest we have a project for every release.

You mean one project for every release version? Or one project for CoD and one for sequel (aka BoM)?

Within on of those projects the incoming bug reports should be checked for being provided with the necessary information.
Only after being checked and being complete in terms of necessary information provided, a bug report should then be assigned to Luthier for nearer observation and feedback requests or status info concerning this bug report.

Otherwise dev team gets spammed and will soon loose interest.
Providing all necessary information for a bug report should be done by the community to get some workload impact off the devs shoulders.

Agreed. I don't think we can enforce a high quality standard for incoming reports. Therefore only reviewed bug reports (confirmed, complete, ...) should be assigned to luthier or one of the devs. It is possible to allow only admins/moderators to assign a report to a person?

[ZG15_FALKE]

Originally Posted by 41Sqn_Banks

You mean one project for every release version?

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.

Originally Posted by 41Sqn_Banks

It is possible to allow only admins/moderators to assign a report to a person?

Yes, sure is!

[41Sqn_Banks]

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.

I've seen that it is possible to add a new versions in the settings. Don't know if this is the feature you are looking for.

Yes, sure is!

This should do it. IMHO reporters don't need to assign a issue. The managers/moderators could manually assign a issue or use the auto assignment by category to assign it to a certain manager/moderator that is responsible for reviewing it. After review it is assigned to luthier.

[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.

[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?

[mazex]

Another thing for users that register on the site. Remember to hide your email address in your profile settings if you don't want to be spammed, by default it's publicly available as this is a tool that is often used internally in LAN:s... The spiders out there are fast

[mazex]

Originally Posted by 41Sqn_Banks

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?

I think that is a good way as we are not an internal team that knows which is the next version As long as everyone knows how to use it. Is it possible to change the text to "Game version" maybe? As there is a lot of localization going on I don't know if that is tough...

Let's force everyone to use the English locale anyway so people don't get confused and start reporting in their native language

[FG28_Kodiak]

Originally Posted by 41Sqn_Banks

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?

I've added the current version to every post, but target version should be renamed, but i don't know how.

Ok seems it's only possible in the translationfiles:
--\redmine-1.3.2\redmine-1.3.2\config\locales
de.yml
field_fixed_version: Zielversion

en.yml
field_fixed_version: Target version