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.
- 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?
If you plan that your make it happen will be included in core (or for example, there are hooks that will need to be added to core for your MIH) then you will want to take a good look at the planned upcoming release cycles (code freeze, alphas, betas) since good co-ordination with the release is essential in getting your MIH out in time. If it is not, then the timeline can be largely independent.
A typical MIH development might look something like the following
1-3 weeks: start up MIH
Initial specifications are written, discussed and finalised on the wiki (see the wiki for more details on what we are looking for from MIH)
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.|
Who develops MIH?
There are typically two ways that we approach MIH. Some MIH are carried out by the core team. Others are carried out by trusted developers on behalf of CiviCRM. We are open to both types. Let us know which would work for you in your MIH page and if you are planning on developing the MIH yourself, please supply a detailed estimate for how long the MIH will take to implement.
Where is the code?
All code is developed from day 1 in a public repository. We recommend that you use github but any long lived public repository is fine.
What license is used for MIH?
All make it happen code is released under GPLv2+ as a minimum. We recommend AGPLv3+.
Who fundraises for MIH?
Anyone can fundraise for an MIH. Typically each person will have a lead who will do some fundraising, but please feel free to join in the efforts if this MIH is important to you, e.g. you could find other similar organisations that would benefit from this functionality and get them to donate, etc. Or you could contact the people who support your organisation and see if they are interested in donating to enable you to deliver a new service, for example.
How do I submit an MIH candidate?
Having a well defined MIH is key to getting funding since organisations are not keen to part with money for ill defined projects. Add you proposed MIH it as a child to the Make it happen candidates page. Ensure that your proposal covers everything mentioned on this page and includes a timetable from start to finish and a detailed budget. Then let firstname.lastname@example.org know. We can then discuss the MIH and once it has been agreed, you can start doing the promotion (writing blog posts, creating content for the make it happen page, contacting people likely to fund, planning other fundraising tactics, etc.)
MIH campaign tasks
The following is a list of tasks to be carried out by people running the MIH campaigns
|In run up to campaign|
|At campaign start|
|When campaign is running|
|After campaign deadline|