mantisbt:development_process
This is an old revision of the document!
Table of Contents
Development Process
Terminology
This process will use the 'work item' as a generic terminology for features or bugs.
Planning a Work Item
- Work should be related to an existing MantisBT issue, if no one exists, create one.
- For non-trivial bug fixes or any features, describe the suggested work in the issue.
- If you need immediate feedback from the core developers, email the dev mailing list with a pointer to your issue. The feedback should be captured directly in the issue rather than the mailing list.
- A change should include a complete change. A checkin should never block releasing waiting on follow up work.
- Contributors / devs should communicate early what they are working on to avoid duplication, major rework, etc.
- Avoid big bang huge contributions when possible.
Targeting a Work Item to Releases
- All work items are expected to be done in 'master' development branch.
- Work items should be ported to the appropriate release / stable branches.
- Targeted branches should be identified during planning stage of a work item and is considered part .
Implementing a Work Item
- Implement the feature / fix in a branch on your fork of MantisBT on github.com.
- Remember to include any corresponding changes to the manual.
Reviewing a Work Item
- Developers should code review the change within 3-7 days.
- Continuous integration system (Travis) must green light the change in github.
mantisbt/development_process.1389759941.txt.gz · Last modified: 2014/01/14 23:38 (external edit)