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.
Principles
- Shipping is what unlocks the value of the checkins we make. Release often.
- Treat each other with respect and value diversity of contributors.
- Do not get tunnel visioned into your own priorities.
- Focus on productivity of the team, rather than just the individual contributor's productivity.
- Checkin rights can be earned and lost based on following our principles and process.
- Good contributions from the community are always welcome.
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.1389760706.txt.gz · Last modified: 2014/01/14 23:49 (external edit)