Table of Contents
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 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.
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.
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.
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.
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.
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
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.