|
|
*Migrated from civicrm.org*
|
|
|
|
|
|
## FAQ
|
|
|
This page contains information about the make it happen program. For up to date details on current make it happen initiatives, see http://www.civicrm.org/make-it-happen
|
|
|
|
|
|
# Requirements for a Make it happen
|
|
|
|
|
|
Make it Happens are not your typical 'feature request' so please don't think of them as your chance to 'blue sky' all the features that you would like in CiviCRM, sit back, and watch the magic happen (if only it were that simple!). Think of MIH as an opportunity for you play an active role in getting some functionality you and others need into CiviCRM.
|
|
|
|
|
|
Please:
|
|
|
|
|
|
- **good management** - MIH need a lead person that will be responsible to guiding them to completion. Note that leading an MIH is a significant commitment. Leads take responsibility for speccing out the requirements, promoting the fundrasing campaign, ensuring that development stays on track, and that the code i properly tested and meet users needs. Of course others will be happy to help and support you in doing this.
|
|
|
- **well specified** - MIH need to be thoroughly and clearly specified since this will increase their likelihood of attracting funding. Put yourself in a potential funder's shoes - would you want to contribute to vague 'improvements' to a module? Probably not. Would you fund specific features that your organisation can benefit from? Much more likely.
|
|
|
- **detailed budget** - it is important that your MIH comes with a detailed budget so that people can see how their money will be spent (including any budget headings for testing, support, etc.)
|
|
|
- **they are fund-able** - one key difference between those thousands of lovely feature requests out there on the forums and our final MIH selection is how likely they are to be funded. We want the majority of our MIH to reach their fundraising goals and try and identify those MIH that are most likely to do so. Make sure that your MIH is attractive to end users and will fulfil their specific use cases. e.g. "Improvements to search" probably isn't as attractive as "Ability to search based relative dates" which probably isn't as attractive as "Smart groups for contacts in certain age ranges, or contacts with activities in specific time periods". In general, the closer your MIH is to the end users goals and use cases, the more it will stand out to them. We don't have a crystal ball, but we have noticed that there is a strong correlation between MIH that have 'seed' funding and those that reach their goals. If you can part/seed the campaign and know a few others that will join in (and you are prepared to cajole them into doing so) that is a good sign.
|
|
|
- **they fulfil an identified need** - MIH that fill a recognized gap in CiviCRM are good. If your MIH fulfils needs that have been requested / discussed a lot on the forums, it stands a higher chance of being successful.
|
|
|
- **they GET FUNDED** - Defining an MIH is the easy part. It just takes a few hours/days of your time. The hard part, and the most crucial part (obviously) is actually getting it funded. You'll need to play an active role in identifying and approaching funders in order to get funding secured.
|
|
|
|
|
|
## What does the MIH cycle look like?
|
|
|
|
|
|
| header | header |
|
|
|
| ------ | ------ |
|
|
|
| 1-3 weeks: start up MIH | Initial specifications are written, discussed and finalised on the wiki |
|
|
|
| 4-6 weeks: fundraising campaign | The time to push to get your MIH fully funded. You should actively promote and fund-raise for the MIH, and solicit help from others in doing so. |
|
|
|
| 4-6 weeks: development and documentation | This is when the development happens :) During this period, funders and developers should be in close dialogue. User and developer documentation should be created during this period. On screen help is best. A new page or two on the wiki is often a very good idea, especially for technical points that might not be of wide interest. Substantial changes to CiviCRM probably deserve changes or additions to the User and Admin guide book. |
|
|
|
| 4-6 weeks: testing | Testing is key to a successful MIH. It's important that people who funded the MIH test early on during this period to ensure that the MIH meets their needs since changes requested after this period won't be within scope of the original funding. |
|
|
|
| Merging into trunk | If you MIH is for a core change being developed by a team other than the CiviCRM core team, then the code will need to be merged into the trunk for the next release, generally before the first alpha version, and always before the first beta. See Developing with the CiviCRM team for more details on the timeframes here. Ensure your MIH has funding for this process. The core team may raise concerns either about the quality of the code in terms of errors in the browser, or in terms of not following the CiviCRM coding standards, or not having sufficient unit and web tests. |
|
|
|
| Release testing | During the Alpha and Beta testing releases, your code will hopefully get tested by other people who may notice new bugs. Plan on having the developers being available to fix bugs raised during this period, and having other people available to do more testing and quality assurance on whatever has changed and other code that may end up with regression errors due to the changes. |
|
|
|
| End: stable released | Your MIH is released. Enjoy! Consider writing a blog post about the new features, explaining the benefits, and making sure to thank the funders. |
|
|
|
| Maintenance and Support | Depending on your arrangement with the Core Team, you may be encouraged or required to contribute to support for the MIH functionality. This can include answering questions on the forum, and fixing bugs that show up in the first release cycle after the code is included in core. |
|
|
|
|
|
|
# Frequently Asked Questions
|
|
|
|
|
|
### When will the code be ready?
|
|
|
|
... | ... | |