Primitive Christianity Revived, Again
This title may seem a misnomer in the rear view mirror, but is meant with a touch of humor, given its abstract feel, and my application: the mundane affairs of keeping our Meetings' records.
A group, for our purposes, is "a set of Friends" like a Committee (Standing or Ad Hoc), a Study Group (like Joe's Bible Study at Multnomah), or even just some annual mailing, PR for Annual Session lets say.
NPYM, the Yearly Meeting, joins the database as one more meeting, of the Yearly Meeting type. Other types: Monthly, Quarterly, Preparative and Worship Group. NPYM may host Mailings but has no Members group as only Monthly Meetings have the two Members and Attenders groups.
Mailings as a rule of thumb need to be opt-in with self-expiry with the possibility to renew, i.e. with a start and a stop date, and a self-timing out. People are often too busy to actively refuse mail, so at least lets turn it off at some point. "Nothing lasts forever" is best to build in.
But then doesn't that apply to most group memberships? They have a start and stop aspect, a duration. Picture a timeline, like a "time tube" with many segments partially overlapping. Perhaps we can simplify our data model and generalize around Service records? That was my query for the other co-designers.
This is a good time in our history to be asking such questions as although we have a formal schema already, etched in MySQL, we've been tentative about flooding it with data, wanting to verify we're moving in the right direction. If we were ever going to simplify the schema, now would be a good time.
The design we're reviewing on npym-it-discuss (a Google Group owned by NPYM's IT Committee), for a data schema, shows Meetings hosting any number of such Groups. The start and stop dates are what's critical as that lets us keep track of a Friend's service record chronologically, even when if said Friend sometimes plays multiple roles simultaneously (not at all unusual for us).
In practice, we may be too lazy or under-staffed to want to keep all this up to date (also not unusual), but at least the structure is clear and the blanks are available. A simple unified design is worth something in itself, and unneeded blanks is less of a problem than needed ones that aren't there.
For example, does everyone who is a member of a Meeting remember exactly on what date Business Meeting approved their membership, after a month of seasoning, Oversight having received a letter and convened a Clearness Committee? Is the archivist expected to go back and dig that out? Of course not, or at least not in 2015. So our dates might be fuzzy or missing on that score, likewise for Attenders (when "first signed the guest book" might be where to get a start date, if you want one, but then some never do while diving in to the life of the Meeting).
The importance of NULL was a big focus early in my term. Every database tends to need at least three value logic, a way to say None. What None means is not always the same. It could mean "we don't know" or "don't care" or it could mean "too contentious to venture an opinion" or "in dispute". Either way, None it is.
Marriages and Households? More groups, just a subtype of same, as remember a Group is "a set of Friends" (everyone is a Friend if a player of any kind i.e. that's just what we call our Individuals). Even a set of one Friend (e.g. Hearthkeeper) or of none (position unfilled) makes sense.
Again, we're more likely to keep the marriage start date field populated, but not be so needy of information when it comes to comings and goings within each household. The start and stop fields are there though, as every filing is about "membership in a group" for some period of time. That's a unifying theme that keeps it simple and therefore satisfying.
In theory, if one Friend moves from street address A to new address B, then from B to C and so on, we would could still keep the whole record -- but in practice we would likely archive or even expunge such information as we're not social or medical workers trying to keep histories. We're not busybodies just for the fun of it.
In any case, I'm not expected to set these policies as someone rotating through as an IT Committee clerk. We're simply party to ongoing management-level decision-making. Any business of any size is going to involve multiple players. Our Executive Committee is already reviewing another of my proposals. Big wheels turn slowly.
When a Meeting takes a marriage under its care, a group is added to the Meeting, called a Marriage. Households often have a shared mailing address or otherwise stipulate a preference for a single communication and exist as a different group type, governed by geographic location. A married couple might join both the Marriage and a Household (as would their children), or not, as sometimes a spouse needs to work somewhere else for an extended period -- an eventuality our schema would have no trouble recording.
Many marriages are not brought forward and placed under a Meeting's care, so our not recording a marriage has nothing much to do with whether or not there is one in the eyes of the State (we'll also see marriages the State doesn't recognize). Our recording a marriage just has to do with whether a Meeting was asked to record it and accepted (see Faith & Practice).
Thanks to all this streamlining, in terms of groups, service records stack up neatly in a single table, be they subscriptions to mailings, periods of service as clerk, tech support, recording clerk, hearthkeeper, webkeeper or what have you, all set memberships with time intervals.
Each Meeting decides its own groups (M&O + Peace + Nominating + Finance + Property would be typical, in terms of committees, of a Monthly Meeting, not of a Worship Group).
Attenders and Members are likewise groups, by default design. You may be a member in one meeting and an attender in another. One of our meeting types is non-NPYM Meeting, meaning you may be recorded as a member of a non-NPYM meeting without our working to maintain an exhaustive list of same (we know they're out there :-D).
All of the above is just a topic for discussion on our listserv. The database as actually implemented is not being used to keep such meticulous records about every Meeting. The database designers hoped Meetings themselves would see the utility in using our designs, but then those designs have continued to evolve, as Friends ponder their social structure against a standard of best practices.
One standard bit of advice I've gotten, when holding up my end in these discussions, is "what do other Quakers do?" i.e. "have you compared notes with your peers in other Yearly Meetings?" What I say back is "great idea, I should reach out more, let me start with QuakerQuaker, which seems quite ecumenical as in diverse". So far, I am not unhappy with this strategy.