Fundraising Agreement / Compliance 
We were hoping that we'd be able to sort our issues of detail with the Agreement out face to face at the Summit, but we couldn't because there was no-one from the Foundation's side able to discuss them. On the plus side, I was put in touch with Moushira - emails circulated to the Board.
The deadline for signing the agreement is 30th June.
There is a further key deadline of October 1st for us to submit a "draft program plan covering major planned programs, events and/or other activities that will be supported with fundraising revenue". Essentially this is a draft budget - though only a draft.
- Action - Chris speaking to Moushira Tuesday morning
- Action - Chris to talk to Andrew
- Action - Roger to ensure fundraising agreement is signed before June 30th
- Action - Roger and Andrew to kick off process to develop a draft budget.
Technical implementation 
This is what we spent most of our time on.
There are, broadly speaking, two options.
A) We implement the fundraiser broadly as we did last year with the Foundation hosting our landing page, donors then being directed to Paypal to make a donation and data being retrieved from Paypal manually and imported into CiviCRM.
My understanding is that this is relatively easy to set up - we did it last year with many fewer resources than we now have - but there is an open question about what development resource we need to support this.
B) We take on a significant project to replicate the Foundation's donation processing system, modified somewhat to suit our needs, on our own server. Basically, doing something like this: http://wikitech.wikimedia.org/view/Fundraising#High-level_Overview_of_Donation_Pipeline
This is in principle very possible as all the code is in open-source MediaWiki and Drupal modules. The benefits of doing this are;
- We are less dependent on the Foundation
- It becomes possible to offer more donation options (e.g. credit card via a payment gateway rather than credit card via PayPal; Direct Debits;) - in turn, there is a cost reduction as Paypal is a relatively expensive payment process.
- This is a platform for future development - unless we do this, we are eternally limited to taking payments only via Paypal.
- We automate two processes which are currently manual - i.e. the sending of receipt emails and the updating of CiviCRM with our transaction details.
The costs are:
- We would need to contract a developer who understands both MediaWiki and CiviCRM - this is a fairly scarce combination.
- There would also be a fair bit of management time involved (I've never managed anyone developing software)
- We'd need a server with a much, much, much higher specification (with an associated cost)
- We would also want to set up a credit card payment gateway and would need to upgrade our PayPal account
Roger and I have done a fair bit of work this weekend scoping this out - see attached Powerpoint. It is possible to implement this but it is dependent on finding the right skills. The Foundation can provide some technical support but only if we have someone implementing it who knows what they are doing, and their advice is to under-automate processes rather than over-automate processes.
The decision on which path to pursue needs to be taken in the next week or two.
Action all - Views please! Agree at Next Exec or by email if necessary
Creative implementation / Testing 
The Foundation is getting on with testing banners and landing pages. We need to participate in this at some stage before the fundraiser actually starts.
There is more resource on the Foundation's side for the creation and implementation of landing pages but we probably want our own as well. I need to get my head around how this actually works before I can tell how much work it is;
If we are taking ownership of the landing pages then a) we can only start participating in the testing when we have completed its implementation b) we have more testing options (e.g. what's the best way of formatting landing pages for recurring payment)
I have quite a long list of value-added fundraising ideas. These haven't been much of a priority this weekend because we've been focusing on the technical stuff, but they include:
- Making use of video appeals on our landing pages
- An email programme for existing / new donors to increase the number of repeat donations
- Feeding UK-based stories into the Foundation's banner/landing page development process
- Creative ideas to localize banners rather than just taking the Foundation's material
Action - Chris to liaise with Pats regarding CentralNotice training
There is obviously a large administrative burden involved; - responding to donor queries - making a daily revenue report to the Foundation (And other chapters) - processing and thanking any offline donations received
All of these things should be in the Office Manager's job description (actually, as the top priorities in the Office Manager's job description). If this vacancy is unfilled then we need to hire on a temporary basis - however that can be reviewed in late September).