[Noisebridge-board] Differentiating affiliate and member donations on Paypal
hurtstotouchfire at gmail.com
Thu Dec 30 14:26:39 UTC 2010
I think that we don't have clear needs defined yet Mark, but we'll
keep it in mind as we start sorting through this.
One of the biggest concerns that people have is the security of the
membership list. To my mind, there are two ways to approach this. We
can keep a detailed master list of members that includes sensitive
information and then we have to protect the hell out of it (very
difficult to get this from any 3rd party service). Alternately, we can
keep a master list that includes no sensitive information and is
genuinely publishable (i.e. has pseudonyms for all members who wish
them) and keep the sensitive information separately, probably on a
machine we own and secure. The treasurer and secretary would have
sufficient information to link pseudonyms to sensitive information
whenever necessary. This would allow us to use cushy third-party
interfaces for our convenience.
Like I said, we're still sorting it out, and I'm not sure how it will
go in the end.
Thanks for your input,
On Sun, Dec 26, 2010 at 20:18, mfburdett at gmail.com <mfburdett at gmail.com> wrote:
> Hi, I do web dev for non-profit orgs for a living, including
> installing and customizing CiviCRM (luckily I get to do a lot more
> interesting things besides that :p) so let me know if you have any
> questions about it.
> The site I made isn't using CiviCRM as that would have been overkill
> for just capturing and listing incoming donations. But it could make
> sense if you want a database and UI for managing memberships, and want
> something that is both off-the-shelf and open-source.
> On Sun, Dec 26, 2010 at 2:30 PM, Kelly <hurtstotouchfire at gmail.com> wrote:
>> Replies inline.
>> On Sun, Dec 26, 2010 at 17:10, Rachel McConnell <rachel at xtreme.com> wrote:
>>> I think that a system for managing memberships and donations ought to
>>> have the following features:
>>> 1. a way to list the current members
>> (+categories of membership)
>>> 2. member identifier that doesn't HAVE to be associated with other
>>> identifying info (such as name or email) but that is associated with
>>> their membership status. This one is hard b/c there has to be SOME way
>>> of doing the association with an anonymous member to the actual person,
>>> and if it's not written down somewhere, it has to be in someone's head.
>> This isn't really necessary. I'll just use a pseudonym in the system
>> if we have a genuinely anonymous member. Right now there's no one.
>> Most people's electronic payment methods de-anonymize them anyway.
>>> 3. automatic reminder emails (to those whose email address is associated)
>>> 4. automatic tracking of received payments
>>> 5. way to list members with late payments who need to be followed up with
>>> 6. reasonable* security around member info
>>> What other features do we Need? It's hard to evaluate systems without
>>> knowing our requirements.
>> Our requirements should be tailored to taxes and non-profit
>> requirements. That means we need to track donations separately from
>> income sources and track each income source separately. I would also
>> say that as much automatic feeding as possible (i.e. from paypal, WF
>> and Square) is a requirement for the treasurer's sanity.
>> I would describe 3-5 differently. Most accounting systems are
>> invoice-based, and this is reasonable. In that model, dues
>> expectations are tracked via invoices, so we want the ability to make
>> invoice templates, repeating into the past and future. We want to be
>> able to view pending invoices for a given person, as well as in total.
>> We need a way to reconcile incoming payments to invoices. We want an
>> easy method for retrieving invoices that could be associated with a
>> given line item of income (right now I just search by name every time
>> and it's ok but it wouldn't be hard to do better). We also need to be
>> able to have income that's not associated with invoices. So far
>> there's no use case for 3, but it's a pretty reasonable feature to
>>> I reviewed the Hackerdojo code that they use to manage memberships (and
>>> other things). It is mostly a wrapper around Spreedly, which is a
>>> wrapper around various payment gateways (such as Paypal). The
>>> hackerdojo system fails on 2 and 6, although these could be added
>>> easily. It uses, as noted, Spreedly for handling 3, 4, and I think 5.
>>> It requires that all payments go through Spreedly, which I think is a
>>> nonstarter for us.
>>> Kelly do you have a list anywhere of systems people have evaluated? I
>>> can start up a spreadsheet otherwise.
>> No list, and no prior evaluations as far as I know. There were a few
>> suggested options that sounded promising in that past thread I posted
>> asking for suggestions.
>>> * 'reasonable' is gonna be hard too, I think. e.g. I would not want our
>>> member info to be associated with our Google accounts, but I also don't
>>> really want it to be in an encrypted database on someone's server that
>>> they have sole control over.
>>> Jeff Tchang wrote:
>>>> I have not personally used it but I took at look at the functioning demo.
>>>> Here is a list of things that made me want to use it:
>>>> - You can add contacts and track their donations
>>>> - It can generate a donor report
>>>> - It is multiuser and seems to have a good deal of functionality above
>>>> and beyond what we need
>>>> On Sun, Dec 26, 2010 at 1:29 PM, Andy Isaacson <adi at hexapodia.org
>>>> <mailto:adi at hexapodia.org>> wrote:
>>>> On Sun, Dec 26, 2010 at 01:22:07PM -0800, Jeff Tchang wrote:
>>>> > I wanted to setup http://civicrm.org/ to help manage this. What do
>>>> you guys
>>>> > think?
>>>> I have a horrible allergy to the acronym "CRM". :)
>>>> Is the software good? What features does it have that would be useful?
>>>> What problems does it solve?
>>>> Board mailing list
>>>> Board at lists.noisebridge.net
>>> Board mailing list
>>> Board at lists.noisebridge.net
More information about the Board