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.
Targeting a Work Item to Releases
- When applicable pull requests should be sent for stable branches.
Implementing a Work Item
- Implement the feature / fix in a branch on your fork of MantisBT on github.com and submit a pull request.
Reviewing a Work Item
- Feedback about the work should be provided within 3-7 days.
- Make sure the pull requests is green lighted via Travis (our continuous integration tool that integrates with github).
- Master should always be open to accept contributions.
- Contributors / devs should communicate early what they are working on to avoid duplication, major rework, etc.
- Avoid big bang huge contributions when possible.
mantisbt/development_process.1389759612.txt.gz · Last modified: 2014/01/14 23:25 (external edit)