Download | Support | Changelogs

 

Documentation:

General Information

Introduction | Overview | Features | Goals and Scope | FAQ Installation | Running an ACE Server | Tracking Problems

 

Community Information

About Us (contact) | Compatible Mods | Contribute | Guides | Missions | Servers | Videos

 

Developer Information

API | Classlists | Compatibility | Modification | Resources

 

Ongoing development Wagn_feed_icon-medium-9343

ACE 1.14 RC1 [2012-10-26]

 

Stable Wagn_feed_icon-medium-9343

   ACE 1.13 for OA [2011-12-23]

   ACE 1.3 for A2 [2010-07-05] (Deprecated)

 

Dev blogs Wagn_feed_icon-medium-9343

1 2 next » (38)

1 2 next » (38)

 

Wheeled by Wagn v. 1.10.7

Versioning

 

Currently: MAJOR.MINOR.PATCHLVL.BUILD x.x.0 is (Pre) Release Candidate x.x.1+ is Release Candidates, where the first one stable enough, is "The Stable Release"

 

 

Bugs

 

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: Bug Reporting

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

 

Features

 

Features are to be rejected when they don't fit into ACE 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.

 

Blocked

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 :)

 

Expired

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.

 

Rejected

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.

 

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

 

 

Documentation

 

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.

 

 

Also see Branching and Patching.