User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:development_process

This is an old revision of the document!


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

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)

Driven by DokuWiki