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.

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

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)

Driven by DokuWiki