New Feature Development
- Ticket is filed in Jira of type 'New Feature'
- Someone (any interested party) writes a feature design document and publishes it
- User community and core developers weigh in
- Document is tweaked with their feedback
- Someone writes an implementation and publishes a patch or repository URL (preferably with tests and documentation)
- Patch / Repository is maintained against the current HEAD/TIP of the active DEV branch by the original author
- Patch is pulled into active DEV branch by current release maintainer
- Maintenance is now the responsibility of the core development team (patches are of course welcome!)
- 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.