Development Process

This process will use the 'work item' as a generic terminology for features or bugs.

• Treat each other with respect and value diversity of contributors.
• Shipping is what unlocks the value of the checkins we make. Release often.
• Focus on building the best bug tracker, make use of services like http://github.com and http://travisci.com rather than hosting or building your own.
• Integrate MantisBT with products users use, rather than providing our own clones.
• Focus on productivity of the team, rather than just the individual contributor's productivity.
• Do your best to provide design and code review within a reasonable time frame.
• Don't lick too many cookies! Focus on few things and make solid progress. Otherwise, you just are blocking others.
• Do not get tunnel visioned into your own priorities.
• Encourage the community to contribute to the project.
• For non-trivial changes, use public branches and get early feedback.
• Use feature branches, rather than “person” or “team” branches. Feature branches are easier to review and integrate compared to a branch that has N tangled features.
• Avoid big bang huge contributions.
• Think twice before making changes that make merge between branches expensive. Such changes may not be necessary or may need to be timed to reduce merging overhead on developers.
• Checkin rights can be earned and lost based on following our principles and process.

• For trivial work items:
  • Link to or open an issue if you want the work to reflect in the release change log.
• For non-trivial work items:
  • Work should be related to an existing MantisBT issue, if no one exists, create one.
  • 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 work item should include a complete change. A checkin should never require follow up work to get to the shippable bar.
• Communicate early what you are working on to avoid duplication, major rework, etc.

• All work items are expected to be done in 'master' development branch.
• Work items should be ported to the appropriate release / stable branches. On principle, only bug fixes should be backported, to avoid introduction of regressions in the stable branches.
• Targeted branches should be identified during planning stage of a work item and is considered part of the discussion.

• Implement work item in a branch on your own Github fork of MantisBT.
• Remember to include any corresponding changes to the manual.
• When ready, submit a pull request including a description of the changes

• Developers should code review the change within 7 days. Developers can work on other features in parallel, so this shouldn't block them.
• There should be at least 2 sign-offs at checkin time. Even with the sign-offs, the waiting time has to be served.
• A developer can request vote or DL discussion if there is no agreement on the pull request.
• Continuous integration system (Travis) must green light the pull request in github.
• If a fix is needed for a release or there are urgency, the author can email the developers DL with the reasoning.

• Whenever history is not important, use cherry-pick to integrate the pull request rather than “github's merge” to avoid the extra merge commit that happens in such case.
• When the history is important, use the “github merge” button.
• Make sure the change shows up as developed by original author and signed-off by the core developer.

• Support latest stable branch.
• Support branch that is in stabilization mode (e.g. release candidates).
• Developers will actively develop on master, but won't support customer instances on it. Customers are encouraged to use stable or release candidates for production, but not nightly builds.
• Goal is to fork for a major release every 6 months.
• Goal is to release a minor release every 2 months including targeted fixes.
• Security fixes can trigger immediate releases for stable branches.

Adding or removing an external library should be discussed first on the developer mailing list.

The following must be considered when reviewing an external library

• Technical fit
• License compatibility
• Recent development activity
• Community size/support

Changing versions of a library does not need to be discussed, unless there are major changes in the review criteria, e.g. change of license