Re: Re-igniting the Membership Committee
Stewart Smith <stewart-qBmou+/[email protected]>
| Newsgroups | gmane.linux.australia |
|---|---|
| Message-ID | <[email protected]> |
I fully realise I'm a couple of months behind on reading this, but thought I'd add in 2c from perspective of someone who wrote/maintained/didn't maintain MemberDB over the years. Kathy Reid <kathy-T0dd/[email protected]> writes: > It's a fair question David - and perhaps I haven't outlined the problem > we're trying to solve clearly. > > The current MemberDB has *broken* functionality in the following ways: > > * Membership reporting is inconsistent, and we require consistent > reporting to meet compliance requirements under the Fair Trading Act > (NSW), as LA is an incorporated association. No doubt. Better than the nothing that was there before, which really isn't a high bar. I'm *thrilled* you're taking on the task of wrangling something better! > * The platform itself is aged, and runs on a difficult to support code > base (an old version of PHP) As the primary author of said difficult to support codebase, I'm 100% behind the idea of using as much as possible of existing projects. Back when MemberDB started, there was nothing else - there was no CiviCRM (there was possibly no Drupal even). If there's one thing I've learnt it's that free time to maintain software is hard to come by, especially something that's niche infrastructure to an org and isn't part of a larger platform of tools. > The current MemberDB has functionality *gaps* in the following ways: > > * Memberships are not renewed, so we don't havea way to expire, or > confirm currency of Membership I'm semi-sure that expirations work, renewals do require SQL INSERT statements though, which is... user hostile. > * There are no targeted communications functionality - so we can't > email subsets of Members, such as those in Victoria, those who are > female - to provide useful information > * We use a variety of tools to manage memberships of committees, and > the current Membership platform does not make this easier. I'd add to the list pretty much every feature it does have isn't really a decent modern implementation of how someone would expect it to work. > A list of requirements was started at; > https://docs.google.com/document/d/1tyTA3Fj5J9XL2D7UTIxw46smXGrLM5J-fI4g6GxK9hM/edit?usp=sharing This is great! It looks as if CiviCRM fufills so many of the requirements that even for the bits that it doesn't, NRE work to make it do that would be maybe a good idea. I think the idea of LA financing development of missing features should certainly be explored