Feature Requests

OpenMAMA is an open source project that accepts contribution from its user and development communities. Input can be in various forms: reporting bugs, submitting patches, requesting new features and writing larger pieces of code are all equally welcome.

As with any project the size of OpenMAMA, we expect our community to have an assortment of features they'd like to see implemented, and a range of opinions regarding the value of those features. To avoid feature requests getting lost amidst the vitriol of our more passionate contributers, and to limit the impact of "Me to" spam on the mailing lists, we've tried to develop a workable process for submitting and debating feature requests. Please try and follow the process where possible, we assure you it's the best way to get things done.

Tracking Requirements and Feature Requests

Requirements and feature requests are tracked and prioritized in public via our Bugzilla instance http://bugs.openmama.org, prior to acceptance into OpenMAMA. This ensures a common understanding of which features have been requested, their relative priority, their development status and when they are planned for release.

If the feature you have requested is determined to be a major one, it is very likely to go through several rounds of feedback within the community. This ensures that a request is strategic to the direction of OpenMAMA before resources are dedicated to implement it, and also that there is a broad understanding of why the feature is needed and that there is willingness to maintain the feature through its lifecycle.

The first step when requesting your new feature should begin with a proposal to the openmama-dev@lists.openmama.org mailing list, in order to notify others, solicit feedback, gain acceptance for the idea, and come to a consensus on next steps. In an ideal world this will also indicate someone who is willing to take on the implementation work, though we understand that not everyone will have that luxury. If you can, have a chat with a few developers (even others on the list) before submitting your request, they may be willing to help.
Please use the OpenMAMA standard format when posting feature request emails.
Next, create a feature request at http://bugs.openmama.org. When you create the request, please be sure that you click "Show Advanced Fields," and select "Feature request" as the category, and include as much detail as you can. One line requests are likely to be ignored/closed pretty swiftly, so try and not make it to easy for us.
The OpenMAMA system or subsystem maintainer will evaluate the request, and determine whether it is a candidate for a future release, at which point there will be discussions between the requester and the development team on the mailing list. If the request is approved, a target release will be set, and development can begin in earnest.

Submitting the Feature

When development has been completed and the code is ready for inclusion into the OpenMAMA testing and release cycle, please submit it as a patch file. The subsystem maintainer, as well as other list developers, will then have a look at the code, try it themselves, and determine the next steps.

Escalation

Sometimes things fall through the cracks, emails get caught in spam, or people take vacations, and a patch email goes unanswered. If you have not received acknowledgment within 5 business days, please resend the email add the line "Patch Escalation: No response for x days" as the very first line of the email.

Best Practices

When submitting a feature request, you should be aware of a few important things that will increase your likelihood of success.

Over communicate your intentions. It is always safe to assume that you know more about your need for a feature than those who will be accepting the patch and interacting with the new code. The more you can tell them about why it is important and how it will fit into the broader OpenMAMA project, the greater the likelihood of success.

The way you request a feature for consideration into a release matters. Open source projects transact on trust and respect. If you want your request to be considered professionally, be professional in your request.
The greater the impact on the rest of the project, the greater the scrutiny it will receive. Features that impact other parts of the project typically take much longer to gain approval for and implement, because others must account for your changes.
Even great ideas may be rejected. If a new feature is not considered strategic by the maintainer, it may not be accepted.
Communicate before beginning the hard work. While having proof of concept code to prove feasibility may help demonstrate the value of a feature, be aware that your feature may evolve before it is accepted. Plan your work accordingly.
Break the work down into smaller chunks. Whenever possible, reduce the task into several parts that stand alone. This makes it easier for others to understand your process and contribute enhancements.
You don't have to provide development resources - but it helps. There are some requests that will garner immediate support from a helpful community of willing developers. There are others that are of limited scope and utility. If the work is non-trivial or a new direction, and you are not providing or recruiting resources, it will probably be rejected by the maintainer because there is nobody to do the work.
Have a plan to maintain the code you develop after release. Be prepared to demonstrate that you have a plan to keep the code fresh and address any currency or security issues associated with it.