Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

New Feature Development

  1. Ticket is filed in Jira of type 'New Feature'
  2. Someone (any interested party) writes a feature design document and publishes it
  3. User community and core developers weigh in
  4. Document is tweaked with their feedback
  5. Someone writes an implementation and publishes a patch or repository URL (preferably with tests and documentation)
  6. Patch / Repository is maintained against the current HEAD/TIP of the active DEV branch by the original author
  7. Patch is pulled into active DEV branch by current release maintainer
    1. Maintenance is now the responsibility of the core development team (patches are of course welcome!)
  8. Eventually DEV is merged into a MAINT branch and feature makes it into stable release


  • You have a better chance of getting a new feature if it is possible to disable it and take no performance hit
  • Changing fundamental behavior is hard, even if you're right - preserving old behavior as an option is often (but not always) a good goal
  • Nothing is risk-free. Trying to convince the core developers otherwise is not likely to win you any points.
  • Ultimately the person writing the design document (and then the code) is in charge - they don't have to accept user feedback they don't agree with. The core development team eventually will decide whether to pull the code into the mainline, but 100% consensus is not required for this to happen.
  • No labels