Membership Database/Format

What follows is a partial description of the XML used for Membership Records on the wiki. Currently only some parts are documented.

CallOutPriority
changes the order of people with a group. It can for instance be used to order the Emergency Callers in the sequence they prefer.

The value is an integer. Lower values are presented first.

If you don't want to specify a value, don't include  at all. The default value of 999 will then be assumed.

OpStatus
One of the fields is called OpStatus, for Operational Status. We aren't required to keep a history for this, so there is only 1 line of current information. OpStatus can be:

Emergency - an Emergency Response Member

Resource - a Resource Member

Non - a Non-Responding Member

BirthDate
The BirthDate field is used for reporting for WCB coverage and determining operational status policy (must be 18 to be an Emergency Response Member).

The format should be YYYY-MM-DD

Phone
Example: 

Phone elements list phone numbers that can reach the person.

The Number is required. It gives the phone number.

Don't use a blank number for an unused entry. Just delete the entire Phone record.

You don't have to give the area code if it's 403. And you shouldn't add a 1 if it's long distance. If there's an extension that's needed, add it after the phone number.

The Location is optional. It gives a brief description of where the person is being called. Standard locations are abbreviated on the call-out sheet: If you use another value for location, it will appear as is e.g. "Calgary:"
 * Work becomes "w:"
 * Home becomes "h:"
 * Cell becomes "c:"

If a person wants to indicate that their home number is also a cell number, they can have multiple Phone elements with the same Number.

  will appear on the call-out sheet as "h/c:627-2460".

Numbers should be listed in the order that the person wants them to be called by the call-out people. E.g. if I always have my cell phone on, I would list that number first.

The numbers may also be called by a machine as part of PCSAR's automated call-out system. If that is used, all numbers are likely to be called simultaneously. There may be some numbers that shouldn't be called by machine, for example, those that are answered by a receptionist who wouldn't know who to transfer the call to. In that case you can add. Format is optional. There's also an old which we don't really use any more but is available if you want to record a fax number.

Status
Each member record has one or more Status lines. E.g.



These elements indicate when the person applied for membership, when it was granted, and when they ceased to be members. They also show when the person changed their membership status, e.g. going from "Associate" to "Voting".

The Alberta Society Act requires us to keep track of this information, even for past members. So we should never delete or change existing "Status" elements, only add new ones with a newer date. In other words, do not change the type and date of an existing Status element; instead add a new one.

The Type can be Member for very old records before the club decided to have separate Associate and Voting classes.

All current members long been classified as either Associate or Voting, so for long standing members you might see something like:

When you classify me as a "Voting" member you'll add a line to look like:

... 





 1997-03-04 (mtg)

...

which shows when they were classified as Voting.

If the member stopped attending meetings in 2002, and then dropped out all together in 2003 you might have lines like this:

... 









 1997-03-04 (mtg)

...

The possible values for Type are

Member - a member before we started distinguishing Voting and Associate. This should never be used for new Status elements.

Voting - Voting Member

Associate - Associate Member

Non - Past Member, i.e. no longer a member. When a person is no longer a member, they're automatically ignored. So it doesn't matter, for instance, if they are listed as being part of a committee or not.

Applicant - not yet a member, but wants to be. Use this when entering information off a new form before the board has approved the new member.

Just a reminder... the society act requires we keep track of at what date members had different member status. That means you can not change  entries. You can only add new ones.

Committee
Each member can be part of one or more committees (or none). By recording the committees the member is a part of, they will automatically be added to the mailing list for that committee.

Add committees, by adding lines like: 

The currently defined committees are:
 * Board
 * Training
 * Membership
 * Preplan
 * Equipment
 * Fundraising
 * Audit

The Role is optional; it doesn't have to be included, but if stated should be one of:

board elected positions:
 * President
 * Vice President
 * Secretary
 * Treasurer
 * Secretary/Treasurer
 * Director

board appointed positions:
 * RCMP Liaison
 * Emergency Services Liaison
 * Staff

committee appointed positions:
 * Chair
 * Co-Chair

Part and Activity
I'm setting things up so that the <Part>'s are matched against the <Activity>'s. This will allow us to automatically calculate participation levels for each members. (So many searches, so many meetings, perhaps even an automatic estimate of number of hours -- useful for funding applications). To work the Description of the Part must match the Activity. Eventually I'll give you a tool to automatically check that, but in the meantime please keep an eye on it. Otherwise I have to make the changes myself. I notice for instance you've added some extra whitespace in the middle of descriptions for some Activities.

I'd suggest you use "Board Mtg." rather than "Reg. Mtg." to distinguish the board meeting (18:00 -- 19:00) from the general meeting (typically 19:00 -- 19:15).

Activity
<Activity> appears in the list of Activities. Each line looks like: <Activity Date="1995-09-21" Description="mtg" Type="Admin" />
 * Date
 * is the date of the activity.


 * Description
 * is a description of the activity.


 * Type
 * is the type of the activity. We track this to be able to produce different types of reports.  Possible values are:
 * Incident
 * a call-out that we responded to. These count towards maintaining a person's SAR Fundamentals certification.
 * Other Group Incident
 * a call-out that the member responded to, but not as a member of PCSAR. Members can record their participation in these types of incidents to show that they are maintaining their SAR Fundamentals certification.
 * Mock
 * a mock incident that we attended. These also count towards maintaining a person's SAR Fundamentals certification.
 * Train
 * a training event other than a mock search. Organizational meetings for training (training committee meetings) aren't training; they're Admin.
 * Post Incident
 * activities that follow up an incident. Critiques, CISM, reviews with the tasking agency.
 * Public
 * public outreach and prevention events
 * Social
 * social events: barbeques, celebrations
 * Admin
 * administration activities. Anything that keeps the organization running but isn't a response or training: board meetings, preplan meetings
 * Fundraising
 * any activity which was to raise funds for the organization