Primitive Christianity Revived, Again
npym-it-discuss content may be forwarded by any subscriber. I'm sharing a recent memo (by me) here to give a snapshot of a regional body of Beanite branch Friends taking care of IT / business.
From: kirby urner <email@example.com>
Date: Mon, 29 Aug 2016 12:26:43 -0700
Subject: update on Regional Directory design (future plans)
To: npym-it-discuss <firstname.lastname@example.org>
Given all this working out with the role-based emails at NPYM, I see the need for our database to keep start and stop dates with every role.
Even requests for timely updates from an announcements list, could eventually time out, and need to be renewed, free of charge.
People lose interest or move on.
We've likely all had to mess with mailing lists that gradually fill up with undeliverables, if not actively maintained.
The design for the regional database I'm behind, proactively maintains just about everything, short of membership, in terms of start and stop dates.
In the case of members, we normally consider that relationship ongoing, unless actively laid down, yet in principle laying down and picking up again is doable, and so should be recordable.
Regarding membership, our NPYM data schema should allow for "being a member" off and on, independently of "through which Meeting". I've already suggested some possible scenarios wherein that might occur. So there's a need for datetime fields there as well.
We need start and stop times for all our clerking and committee positions. Sometimes we'll use NULL and leave it empty. We don't know the future.
This addition of a strong timeline dimension was my primary innovation in the mock-up, which actually gives realistic snapshot output for some Multnomah Meeting committees, during a specific time window:
With such records, you could easily reconstruct who was serving on what committee when. That's pie-in-the-sky in today's IT-poor era, but someday we might have more interest in IT. As a clerk of the IT Committee, I'm not out of character in hoping that might come to pass.
Having our myriad slates auto-generate from the database such that any smartphone with the right URL could browse the current (or a past) slate, for NPYM at least, if not each Monthly Meeting, is the worthy end goal. If smartphones can do it, big screen TVs can do it. They're all just differently aspect-ratioed and scaled versions of the same generic device.
We'd need a front end for HTML views (more cosmetic), and "back door" URLs for pure JSON, for those needing bulk data for their spreadsheets or whatever.
Does that all sound like gobbledy-gook?
Check out this example of a Python Flask application and follow links to learn more.
(at this time a "teaching application" I use with my on-line classes, new course starting Sept 20, already full I think, plus you need to be from California for that one).
Apigee does a good job explaining the importance of APIs as a kind of contract with the general public. Things break when it changes, so best to define it and stick to it, maybe changing the implementation.
As Quakers, I don't think we're immune from making binding commitments from time to time, as led by our testimonies, and ultimately the Spirit.
Having our Directory available on any smartphone would illuminate "who are the NPYM Friends" in the area. That's the kind of information NPYM should be up for sharing. That'd be "being the Quakers the world needs us to be."