QuakerQuaker

Primitive Christianity Revived, Again

Group Theory

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.

1 member likes this

Comment by Kirby Urner on 12th mo. 7, 2015 at 6:34pm: Followup query: how might one cast "the record-keeping needs of a Yearly Meeting" against the backdrop of an early schism among Friends, between those championed by Fox, proposing structure, and those feeling guidance by the Inward Light was guidance enough, Rogers an early exponent of this school of thought? Is the same tension still with us today?

www.quakerquaker.org/profiles/blogs/william-rogers-we-were-taught-t... (Keith Saylor on this early controversy).

Comment by Kirby Urner on 12th mo. 12, 2015 at 8:03pm: I've added Outside NPYM as another Meeting type, not that we're obligated to instantiate a lot of those, but out of our own wish to record a relatively complete picture, we may add such as Hillsdale Friends and This Little Light of Mine (Worship Groups), neither currently in our Chronology.

Comment by Howard Brod on 12th mo. 13, 2015 at 7:40am: Seems you need to account for the fact that increasingly liberal Quaker meetings are not requiring membership in order to fully participate in the life of the meeting. This is occurring because a number of Friends increasingly feel that "membership" in a spiritual association is counter to the reality of the Spirit. This trend among liberal Friends is growing. My meeting, although gaining more participants by the week, has not had a membership request for a long time. And the meeting is about to appoint as clerk of the monthly meeting a Friend who is not a member. Likely, 80% of active Friends in my meeting are not members on principal - due to a desire to avoid unnecessary outward forms in the life of the meeting.

Comment by Kirby Urner on 12th mo. 13, 2015 at 11:54am: The schema I'm proposing treats Members and Attenders as two types of Group a Monthly Meeting might host (Yearly and Quarterly Meetings host neither, as membership is the business of Monthly Meetings only).

As a Friend, I might join either group within a Meeting and in historical fact have been a member of Multnomah on and off ("on" as a small child, "off" while living in Rome, my nuclear family eventually transferring membership to Florida Avenue Meeting, in DC if I remember right, then back to Multnomah, then jumping over to Attender again, even while doubling my responsibilities... was that my year as Assistant Clerk?).

NPYM recognizes the Member / Attender distinction, even while I agree it's of fading relevance in many meetings. Rest assured there's nothing in the schema to prevent an Attender in Meeting X from holding any specific position or joining any committee.

A given Meeting may have its policies though, sometimes claiming for legal reasons, regarding keeping "top officers" a members-only thing, but that's not something the table structure enforces in any way. Speaking for myself, I think Attenders at every level, especially on Oversight, helps keep a Meeting honest, as these Attenders are often in "try before you buy" mode, i.e. thinking about becoming Members but wanting to be convinced of the integrity of a Meeting's inner workings first. I encourage that approach. Serve on committees for a year or more before deciding you're ready to become a "public booster" of the institution (what a member is in many ways -- someone willing to openly declare allegiance / loyalty to a certain Society of Friends).

One may also be a member of a meeting outside NPYM, with attender status locally -- other possibilities may suggest themselves. Indeed, what I wanted to be able to data-model was a family (say) resigning in protest when a Meeting got "too something" (left to the imagination), then years later, rejoining as members again, when the Meeting had come around. What's happened once might happen again. Our timeline should show all this i.e. what data structure will record these ins and outs? Mine does, because membership in *any* "group" comes with a start and stop date, even if the recording clerk entering service records doesn't choose, or have the info, to fill them in.

Comment by Howard Brod on 12th mo. 13, 2015 at 4:54pm: Sounds like you have it covered, Kirby! Out of the seven Trustees at my meeting, three of them are not members. Since the meeting has recognized that most seekers attracted to liberal Quakers in these parts have a disdain for membership, so we have written in our meeting's procedures that we do not make any distinction whatsoever between members and attenders and membership is only used when the Friend prefers it for their own personal journey. It's never implied that it is required to be a Quaker. Commitment to our meeting and Quakerism is demonstrated by a choice of involvement in the life of the meeting.

Comment by Keith Saylor on 12th mo. 13, 2015 at 9:07pm: Kirby.

Reading your discussion with Howard has me thinking of a routine in the database but I can't get my mind around it yet. I'm just going to free write and see how it strikes you and perhaps you can run with it. Year ago I worked in cgi script creating a database for wild bird observations. I'm not familiar with SQL. I wonder what would have if you were to write a routine that was triggered from the data entry form (maybe a simple yes or no drop-down menu) that automatically generated of unique number or a unique sequence of letters that represents the individual who is an attender but not a member. That unique sequence of letters or numbers or both literally represents the individual but neither the individual attender nor the database manager or data entry person know specifically who the person is. So, the meeting shares the number of members and their names and it also shares the number of attenders with no names. So, when the numbers of attenders are shared again at a future date, if there is a difference from the current numbers in the database the adjustments would be made accordingly by merely adding new randomly generated "names" or deleting any randomly generated name if there are less attenders.

The randomly generated names are also given a value of negative one through a sub-routine triggered by answering yes or no to the question of whether the data point is an attender or member and the members are given value of plus one. Some interesting data sets could be generated from these values. Imagine running a query as to the people of a particular Meeting that included both the members and attenders. The positive and negative numbers would offset each other, however, the results might show a positive number that doesn't represent the actual numbers of people in the Meeting but that there is, say, three more actual members than attenders only, There is something else of value to this negative designation of attenders that I just can't extrapolate in my mind. Anyway, just some random thoughts. I also like that the attenders are completely anonymous up and down the data entry and storage routine.

Comment by Kirby Urner on 12th mo. 14, 2015 at 12:55am: Hi Keith --

The workout / exercise I'm currently engaged in is (A) working through the slate of one of our most complicated Meetings (Multnomah), which has its slate published here:

https://www.quakercloud.org/cloud/multnomah-friends-meeting/resourc...

and then (B) the slate of NPYM, the Yearly Meeting itself. It has this PDF:

http://npym.org/?q=npym-slate

Here's a snapshot of how far I've gotten so far, in terms of sending data to a browser, drawing from a database (clicking on the picture makes it big):

These are but snapshots in time, showing current terms, but what about going back and reconstructing the record? We could go back to the 1950s at least (talking about our Beanite Branch, refugees from Iowa who moved to Left Coast Nation (this part of Oregon more like Vermont)).

Even if we choose not to do that (reconstruct our service records in a single database), the schema should suggest it can be done. Plus we might want to do it going forward. By just entering a small part of the data, a few cups, I give it grist for the mill.

Part of me wanted to go straight to a Neo4j graph database, however I'm on the hook to teach a course featuring a classic web application, and frankly I understand SQL whereas I'm relatively inexperienced with the newer noSQL zoo: MongoDB, CouchDB, Cassandra... Neo4j.

I mostly just read about these things, though I did a tutorial on the latter and actually started on some Quaker stuff with it. But I'm not able to leap tall buildings in a single bound. I've got a life outside my computer.

Instead, I'm hacking away in my laptop-sandbox using public data (URLs above), and share the code with my students, as a kind of use case and textbook example. "Quakers: a business-oriented cult that reached its peak in the 1790s" I tell my students, mostly Bay Area geeks from what I can tell.

NPYM is typical of nonprofits in the USA today: stuck in spreadsheets, probably tried to go with Microsoft Access but then the affordable multi-user web-based approach is more LAMP stacks, which is Linux. Sorry for the jargon, you probably follow.

Quakers are more social workers, teachers, meaning more likely to know Windows -- unless in a college setting e.g. Earlham, where they're more like MIT etc. in sticking with POSIX.

If we really get our data organized, statistical studies such as you suggest would be quite doable. The key is to preserve the either / or distinction, i.e. to have our Meetings continue to make those two groups. All the Monthly Meetings in my sandbox so far do.

There's ambiguity in the concept though, in that a member, and therefore a member of the Religious Society of Friends (RSoF), might undo a membership here (resign from Monthly Meeting A) while creating a membership somewhere else, so a second joining of RSoF? Not that realistic but the point is membership in a specific Monthly Meeting tends to double with membership in the Society as a whole, and some might claim to quit a Meeting while not resigning from Quakers in general. Corner cases.

Put another way, unless someone transfers their membership from another meeting, done by letter with that meeting's clerk, we often have no way to verify someone's claim to be a Friend in "another meeting". Whatever. We should just start fresh if no letter of transfer is forthcoming, as a matter of policy, so it's nothing personal. I don't see anything wrong with going through the membership process a second or even third time -- a kind of renewal. Some people re-marry the same partner.

I like the ceremony of writing to Oversight and having a Clearness Committee. We actually let Attenders serve on such Committees for Clearness, as we want non-members to see our workflows from all angles, just like a prying journalist would want to. We don't have members-only doors, or secret rooms or... Open Source (transparency) is more the name of our game.

Besides, some of our founding families and oldest hands never bothered with Membership, suspicious of the whole concept. If you don't let them call you a member, then they can't take it away later (whatever "it" is). The Pinney family, for example, were among the first to find a home on Stark Street, now that Electroscientific was ready for bigger digs. Our "parent company" was founded by conscientious objector types who admired the AFSC, which had the front office.

Definitely we're talking the same language, e.g. cgi scripts. I've got SQLite for a back end, meaning a file I can share around, a ship in a bottle, without making others buy fancy expensive stuff. The software to study NPYM.db is free, but requires learning some SQL.

Exactly, what every recording clerk should know. :-D

Comment by Kirby Urner on 12th mo. 31, 2015 at 6:15pm: Here's a snapshot of the source code for said NPYM.db project, as of Dec 31, 2015:
https://github.com/4dsolutions/NPYM

Kirby

Comment

You need to be a member of QuakerQuaker to add comments!

Join QuakerQuaker

RSS

Welcome to
QuakerQuaker

Sign Up
or Sign In

Or sign in with:

Support Us

Did you know that QuakerQuaker is 100% reader supported? Our costs run to about $50/month. If you think this kind of outreach and conversation is important, please support it with a monthly subscription or one-time gift.