Author Topic: Membership Management Program  (Read 3063 times)

0 Members and 1 Guest are viewing this topic.

dewey

  • Administrator
  • Guru
  • *****
  • Posts: 68
Membership Management Program
« on: May 06, 2008, 12:01:01 AM »
FIRST POST - this is a reply to an email conversation that was moved here to start this discussion.  Anyone is welcome to join in and post their opinions, ideas, etc.

We are discussing the need for a membership management program and the merits of using one system over another, what needs to be stored about members, and how access will be controlled among the people involved.

The initial parties of this discussion are Jack LaPointe, Membership Chair, Barbara De Mase, Treasurer, Dewey Williams, webmaster and tech support, and Bill Barnes, President.

------------------------------------------------------------------------------------------------------------

Bill Barnes (1) wrote:
>
> First of all, Barbaraís question from another email:
>

>
> We are a 501c Corporation and are not (to my understanding) required to file any returns. The ByLaws are at http://pc3.org/business/ and the president has the original executed documents.
>
> ---------
See my previous email about a "new" tax law concerning non-profits.

> I agree that a database is the appropriate environment, but question whether our handful of records warrents the programming and hosting load. Iím also hesitant to commit ourselves to a PHP/SQL environment which might suffer neglect or disaffiliation (no offense). Is there any way we could have a shared file with a check-out process that if Jack is working on it, itís unavailable to anyone else? Dewey is the one who the work will fall to and who has the experience to answer these concerns.
I agree that we have a fairly small group of records, hopefully it will increase over time.  The morass of information we have now is partially due to not having a centralized membership database that is accessible by all those involved - mainly membership chairman and treasurer. Moving to a centralized multi-user or a single editor system is necessary to keep the system from becoming corrupted.

Any file-locking/check-in/check-out technique I know of is built into specialized software such as DreamWeaver, Contribute or various version management programs used to track multiple versions of code by developers (CVS and SubVersion are popular examples).  I was hoping a open-source membership management program was readily available but I only found a few listed in SourceForge, most in little or no form but vaporware.

>
> An interesting technique Iíve used in other situations; except here it has serious security concerns: One person could host a simple file (.xls or .mdb) on their computer and others could access it at a verified computer through a free VPN I use. It would appear to the users like any locally networked file with appropriate file or record locking. The issue is that I havenít researched how to restrict the VPN to a single share and not open the entire host to everyone on the network. IF I were certain that all of my personal shares were protected with user name and password, that might be adequate among friends. Unfortunately, my file server contains a hodge-podge of data dating back to FAT16 documents (it may even have some FAT-based shares that are inherently unsecurable) and donít know that it could be restricted.

I am not certain that you can lock a file through Windows/VPN.  Other problems arise, what if the user forgets to unlock the file or cannot due to lost connection?  It also requires a number of technologies and user expertise to put in place and maintain.  FTP to/from the web server might work, but still, no file locking capabilities so we still have the potential for multiple versions.

>
> Dewey:
>
> One more field that I always add to databases like this is a Date Modified (or verified) for each record. Then I know that if this contact information is 5-years-old without having been refreshed, itís probably suspect.

I agree that a modified date is useful but I am not certain how to automate one so it updates when ANY field in the record changes.  I know it can be done in a db, but not certain how to implement that in Excel without some major code.

> I definitely want to be at least ex-officio in the subcommittee. In the interest of open meetings and more importantly, our educational mandate, we should invite the membership to at least watch over our shoulders. Who knows, someone may become so enamored of what weíre doing that they volunteer to maintain it.

We should move all our discussions to the forum.  Members can join in, see what we are discussing and maybe have some ideas we don't think of.

Maybe I am trying to make this too difficult, fancy, hi-tech.  Here is how I see it.

We need a way to store:
current member information, including, contact info, when dues are paid, when they are due, etc
enter new member information
contact members when dues have expired
contact previous members to let them know what the club is doing and invite them back
create membership and treasurer reports for board meetings, newsletter, etc.

Methods:
1) Use an Access program or Excel file.  Only ONE person ever edits this file.  All changes are sent to that person by email from any others that gather data concerning that file - in our case, the Treasurer and Membership Chair.  This places all the work on one person - although with our small group that is not a LOT.  The "keeper of the file" can send copies to anyone needing to see the data.  These can be locked/protected so they cannot be edited (at least in Excel 07 - is this true in Access(any version) or Excel 03?).  Another way to insure this would be to send a PDF of the file instead of an Excel file.

2) Use Access program or Excel file.  Allow those needing data entry to make changes to file.  User must then send new version to each person holding file.

3) Use Access/Excel.  Store file in central location (website?) and download/upload using a file check-in/check-out system.

4) Use web-based multi-user member management application.  The problem here is that the ones that exist cost money ($180.00 - $1000's), may not suit our needs and will need to be heavily modified or we have to write our own.


Dewey

BillB

  • Officers
  • Guru
  • ****
  • Posts: 194
Re: Membership Management Program
« Reply #1 on: May 06, 2008, 10:15:00 AM »
Quote
I agree that a modified date is useful but I am not certain how to automate one so it updates when ANY field in the record changes.  I know it can be done in a db, but not certain how to implement that in Excel without some major code.
Quote
3) Use Access/Excel.  Store file in central location (website?) and download/upload using a file check-in/check-out system.

For our people doing entry and our data, I am not afraid of doing things by hand. I assumed the the "modified date" would just be entered as we made the change. Our "check-out" system could be as trivial as renaming the file when we copy it home for editing.

Of course, I don't appreciate how comfortable I am with steps I have done hundreds of times. To me, it's straightforward to ftp, rename original, open another window to edit the file, ftp back to server, test new file, clean up old files. We have had experienced users who struggled with ftp because it was not in their routine. Today we have 2 people who would edit the file and might need hand-holding to get set up with this.

No matter how we handle sharing, it needs to be restricted. We don't want every webcrawler reading our mailing list.

Bill
« Last Edit: June 12, 2008, 11:33:00 AM by BillB »

dewey

  • Administrator
  • Guru
  • *****
  • Posts: 68
Re: Membership Management Program
« Reply #2 on: May 06, 2008, 11:20:02 AM »
Perhaps we are looking at this in the wrong way.  Do we need one file to hold all data - or would it be better if Membership and Treasurer had separate files, considering that they need to store different information?

Update info from one person to another could be passed as easily as in an email, such as, "update Jim Doe address to 111 Byte St., change email to jdoe1@imadoe.com". No need to send the entire file. Not as high-tech and fancy as I would like it but maybe easier for those doing the work. 

In my scenarios below, the only common data is contact information and whether member is active or not.  Jack and Barbara may have other ideas on things to track, but this is a start.

Treasurer Tracking
member contact info
membership type
last payment date
payment type
due date
last update

Membership Tracking
member contact info
active member (yes/no)
active date
member since
member interests
last update