« Previous - Version 190/226 (diff) - Next » - Current version
Sickboy, 02/16/2010 12:26


Welcome to the A.C.E. Advanced Combat Environment Mod for ArmA 2!

Reporting issues, bugs, feedback


Goals / Scope





Function Documentation


x.x.0 is release candidate
x.x.1 is first stable release from that version.


Coordinated work

Noone can bear the whole mod development on it's own.
In that regard it appears to be useful to coordinate workflow to achieve current tasks.

Personal ticket
For better overview if a developer plans to work on a certain feature (further called feature X) there should be a TASK ticket created with detailed information about the feature component and who is going to work on it as main author.

Skype announcement
Addtionally the author should inform other developers in the Skype groupchat about the creation of the ticket, so developers are aware of it and can respond to the ticket if needed.

Responds can include:
- Notification about a similar (maybe unknown) project already going on
- Stating ones interest in the project and asking for participation

Sharing tasks
Due to the nature of hobbiest developing it should become common sense to ask for help or support, rather than trying to achieve a certain goal all alone.

The benefits of sharing tasks are:
- Faster achievement of a goal
- Less workload
- Bug hunting during design
- Feedback during design


Each feature should be documented. At least it's description. But especially usage information, if applicable.
Once a component is added to the repository, basic documentation should be up in approx. 2 weeks. Write it up yourself, or ask the document maintainers to help.


Insufficient bug reports that lack of RPT, reproduction steps or anything else that would be needed to fix, are replied with the general wiki page about bugs.
Reference: http://dev-heaven.net/wiki/ace-mod2/Bugz

Bugs ideally, if requirements are met, should be assigned to the original author of the component.


Features are to be rejected when they don't fit into ACE2 scope. A short explanation is helpful to stress out mismatch with set scope.
Features are generally free to be assigned to oneself if a certain feature attracts a developers liking.
If a feature fits ACE, but is not possible due to lack of resources, the ticket should be added to the Future Milestone, and set to Low priority.


If certain tickets are not able to be completed, before others are done, please don't reject these tickets but set the blocking ticket to 'blocks' this ticket.
If more tickets appear about the same, set them to Duplicate, and not Rejected :)


When tickets are set to feedback, if there is no response within 14 days, the ticket is set to Expired.

Tracker clearance

To avoid abandoned tickets or identify possible expired tickets, it would be useful to set a due date to each ticket once it is created.
Due date should cover the 14 days timespan (to help filtering), so tickets that are theoretically due and have little to no useful feedback can be set to expired.


Rejecting tickets should be done with a short explanation or at the very least; reason.
Rejected tickets should disappear from the Roadmap. So please remove version on reject.